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This  dissertation  develops  a  methodological 
approach  for  requirements  analysis  and  specification  that 
utilizes  conceptual  modeling  to  incrementally  develop  and 
formally  specify  requirements.  The  methodology  provides  a 
graphical  formalism  for  specification  within  an  object- 
oriented  framework.  Classification,  generalization,  and 
aggregation  are  utilized  for  organizing  and  identifying  the 
requirements  of  a  system.  The  modeling  strategy  integrates 
conceptual  modeling  concepts  such  as  hierarchical 
structures,  the  role  of  the  environment,  and  a  temporal 
structure  into  an  object-oriented  framework  that  emphasizes 
information     hiding,     data     abstraction,     and     inheritance. 

ix 


This  truly  unified  approach  results  in  requirements  that  are 
reliable,    modifiable,    and    easy    to    understand. 

Requirements  Modeling  Language  Prime  (RML'),  a  formal 
requirements  specification  language,  was  defined  to 
simplify  the  syntax  and  extend  the  underlying  semantics  of 
Greenspan's  RML.  The  graphical  components  of  the 
methodology  are  formally  defined  in  RML'  and  the  results  of 
the  methodology  are  a  formal  requirements  specification 
expressed    in    RML'. 

This  dissertation  addresses  the  problem  of 
requirements  modeling  from  a  knowledge  representation 
perspective.  One  of  the  major  tasks  addressed  by  this 
research  was  to  discover  what  types  of  knowledge  should  be 
expressed  during  the  various  stages  of  requirements 
acquisition  and  to  determine  how  to  best  represent  that 
knowledge.  The  methodology  incorporates  this  information 
and  guides  the  analyst  through  the  entire  requirements 
modeling    task. 


CHAPTER  1 
INTRODUCTION 


Software  development  in  the  1960s  was  in  its  infancy 
and  was  characterized  by  zealous  developers  trying  to 
discover  innovative  ways  to  utilize  computer  technology.  In 
the  late  1960s,  the  field  of  software  engineering  emerged, 
based  on  the  idea  that  an  engineering-like  discipline  could 
be  applied  to  building  software  systems.  In  the  two  decades 
since,  there  have  been  significant  advances  in  the  area  of 
software  development  techniques.  However,  current 
researchers  are  still  searching  for  a  solution  to  the 
problems  associated  with  the  "software  crisis." 

The  term  "software  crisis"  refers  to  the  fact  that  a 
significant  percentage  of  delivered  software  systems  were 
completely  unsatisfactory,  extremely  late,  far  over  their 
budgets,  and  poorly  suited  for  the  intended  users  of  the 
system.  The  reasons  cited  to  explain  these  failures  focus 
on  a  lack  of  communication  between  the  developers  and  the 
users,  a  lack  of  understanding  of  the  problem  and  the 
environment,  and  overly  optimistic  estimates  regarding 
development  time  and  cost  [Was80].  Consequently,  many  of 
the  problems  associated  with  the  software  crisis  can  be 


attributed     to     deficiencies     in     the     earliest     phase     of     the 

software    life-cycle. 

There     is     currently     no     consensus     on    what     to    call     the 

earliest     phase     of     the     life-cycle     or     how     it     should     be 

defined.        The    term    requirements     analysis    and    specification 

is    used    in    this    dissertation    for    the    first    life-cycle    phase. 

This      phase      consists      of      two      distinct      components: 

requirements     analysis    and     requirements    specification.        It 

should    be    noted    that,    although    the    following    definitions    are 

representative    of     the     general     usage,     these    terms    do    not 

reflect    a    standard. 1 

Requirements  analysis  is  the  process  of 
gathering  all  of  the  relevant  information  to  be 
used  in  understanding  a  problem  situation  prior  to 
system    development. 

Requirements  specification  is  the 
documentation  of  the  requirements  analysis 
[Gree82] . 

Because     the     problems     associated     with     the     software 

crisis     originate     during     requirements     analysis     and 

specification,     the     ramifications     affect     all     aspects     of 

software    development,     but    are    particularly    significant     for 

maintenance.       Errors    introduced    during    the    earliest    phases 

of    development    are    the    hardest    to    correct    and    take    from    1.5 

to    3    times    the    effort    of    an    implementation    error    to    correct 

[Yeh84].       In    terms    of    cost,    software    maintenance    constitutes 


lThe  term  requirements  definition  is  often  used  to 
describe  the  analysis  process.  It  is  also  used  by  other 
authors  to  define  the  documentation  of  the  requirements 
analysis.  Because  of  this  conflicting  usage,  alternative 
terms    were    chosen. 


between  66%  and  80%  of  the  life-cycle  cost  and  about  two 
thirds  of  that  cost  can  be  attributed  to  misconception — 
not  identifying  the  real  needs  or  improper  conceptual 
modeling    [She87]  . 

The  lack  of  thorough  attention  to  requirements  analysis 
is  even  more  significant  in  large,  complex  projects.  In  two 
large  command-control  systems,  67%  and  95%  of  the  software 
had  to  be  rewritten  after  final  delivery  because  of 
mismatches  with  user  requirements  [Boe73].  In  some  cases,  a 
lack  of  attention  to  requirements  results  in  entire  projects 
being  cancelled  due  to  the  inf easibil i t y  of  successful 
completion.  Two  expensive  examples  are  the  $56  million 
Uni vac-United  Airlines  reservation  system  and  the  $217 
million    Advanced    Logistics    System    [Boe84]. 

It     has     been     shown     that     insufficient     effort     spent     on 

requirements     analysis     and     specification     can     result     in 

increased    maintenance    costs    and,     in    extreme    cases,    can    lead 

to     the     total     cancellation     of     projects.        However,     these 

economic     ramifications    are    only     part     of     the     problem.        The 

role     played     by     the     requirements     specification     is     so 

pervasive     that     the     success     of     the     entire    project    depends 

upon    it.       This    scope    is    discussed    by    Yeh    and    his    colleagues 

[Yeh84,    p.    519-520]: 

It  is  the  basis  for  communication  among  customers, 
users,  designers,  and  implementers  of  the  system, 
and  unless  it  represents  an  informed  consensus  of 
these  groups,  the  project  is  not  likely  to  be  a 
success.  It  must  also  carry  the  weight  of 
contractual  relationships  between  parties  that 


sometimes  become  adversaries.  In  particular,  the 
design  and  implementation  must  be  validated 
against  it.  ...  In  short,  because  the 
requirements  phase  comes  so  early  in  development, 
it  has  a  tremendous  impact  on  the  quality  (or  lack 
thereof)  of  the  development  effort  and  the  final 
product . 

The     requirements     phase    is    often    primarily    associated 

with    the    task    of    identifying    user    requirements.       Obviously, 

that    is    one    necessary    component,    but    the    primary    purpose    of 

requirements     analysis     and     specification     is     to     gain     a 

thorough     understanding     of     the     problem     situation     and     to 

communicate     that     understanding     to     others      [Fre80]. 

Consequently,     researchers    have     proposed    solutions    to    the 

requirements    problem    that    include: 

1.  constructing  conceptual  models  to  aid 
understanding ; 

2.  developing  better  requirements  methodologies; 
and 

3.  expressing  requirements  in  formal  languages 
for    unambiguous    communication. 

Due  to  the  complexity  of  systems  today,  an  additional 
layer  of  understanding  is  needed  between  the  real  world  and 
the  requirements  specification.  Many  researchers  have 
proposed  constructing  a  conceptual  model  during  the  early 
stage  of  software  development  to  assist  the  analyst  in 
understanding  the  problem  situation  before  the  solution 
system  is  described  ([Rou79],  [Bub80],  [Rol82],  [Gre84], 
[Yeh84],     [She87],     [Kun89],     and     [Som89]).        For     all     but 


trivial  systems,  this  explicit,  precisely  defined  conceptual 
model  is  needed  to  share  that  understanding  with  the  group 
of    people    involved. 

The  precise  contents  of  the  conceptual  model  vary  with 
the  researcher,  but  generally  it  is  viewed  as  an  abstract 
model  of  the  application  reality,  i.e.,  the  system  within 
its  environment.  It  should  be  designed  by  the  use  of 
abstraction  and  negotiations  between  users.  It  describes 
the  users'  views  of  the  context  of  the  system,  often  with 
multiple  views  being  significant.  The  model  typically 
identifies  major  user  services,  important  relationships,  and 
all  external  properties  of  the  system.  It  depicts 
abstraction,  assumptions,  and  constraints  about  the 
application  and  usually  views  the  application  in  an 
extended  time  perspective.  In  short,  the  model  forms  the 
semantic    basis    for    the    contents    of    the    system    [Bub80]. 

Another  proposed  solution  to  the  requirements  problem 
involves  developing  better  requirements  methodologies.  The 
lack  of  methodological  approaches  for  requirements  modeling 
is  frequently  acknowledged  in  the  literature.  Shemer 
[She87]  states  that  the  lack  of  a  framework  for 
understanding  creates  confusion  and  poor  performance  in 
practicing  analysts.  Without  the  proper  conceptual  tools, 
analysts  focus  on  the  technical  aspects  of  the  developed 
system  rather  than  on  understanding  the  problem.  Shemer 
cites     Freeman     as     stating     that     too     frequently,     too     many 


6 
analysts  are  not  producing  the  results  that  are  needed  and, 
moreover,  are  incapable  of  producing  them  because  analysts 
are  lacking  appropriate  intellectual  tools. 

The  inadequacy  of  current  approaches  for  requirements 
modeling  is  also  acknowledged  by  Yeh  and  his  colleagues 
[Yeh84]  and  is  attributed  to  the  fact  that  most  techniques 
concentrate  on  functional  requirements  and  provide  weak 
structures  for  expressing  them.  They  state  that  current 
techniques  primarily  offer  tools  (predominantly  languages), 
rather  than  guidelines  for  analysis  or  specification. 

Another  proposed  solution  to  the  requirements  problem 

focuses  on  the  use  of  formal  specification  languages. 
Current  software  requirements  documents  are  usually  written 
in  natural  language.  Problems  resulting  from  using  natural 
language  for  specifying  requirements  have  been  widely 
reported  ([Bel77],  [Ros77a],  and  [Gre84]),  and  include: 
unstated  assumptions  and  undefined  concepts;  ill-defined  and 
ambiguous  terms;  requirements  mixed  with  design  and 
implementation  decisions;  poorly  organized  or  fragmented 
descriptions;  monolithic  requirements;  and  inconsistent  and 
incomplete  descriptions. 

One  alternative  to  specifying  requirements  in  natural 
language  is  to  express  them  in  a  formal  requirements 
specification  language.  A  formal  specification  language  is 
one  whose  vocabulary,  syntax,  and  semantics  are  formally 
defined,  i.e.,  based  on  mathematics.   Formal  languages  for 


7 
specifying     requirements     include    RML     [Gre84],     the     language 
used     in    the    CIAM    approach     [Gus82],     Gist     [G0I8O],     REFINE 
[Rea87],    and    ERAE    [Dub89]. 

It  is  believed  that  expressing  requirements  in  a  formal 
specification  language  should  lead  to  an  unambiguous 
requirements  specification,  and  as  such,  should  be  ideal  as 
the  basis  of  a  contract  between  developers  and  system 
procurers.  Regardless  of  that  potential,  formal 
specification  is  not  widely  used  because  of  the  lack  of 
familiarity  with  these  new  techniques  and  because  formal 
methods  appear  to  be  difficult  to  use  due  to  their 
proximity  to  mathematics  and  logic.  Furthermore,  as 
Sommerville  [Som89,  p.  93]  states,  "Unfortunately,  the 
current  state  of  user  experience  (and,  realistically,  the 
experience  of  many  software  engineers)  is  such  that  they 
would  not  understand  a  specification  written  in  a  formal 
specification  language  and  would  be  unwilling  to  accept  it 
as    a    contract    basis." 

Thus,  it  is  assumed  that  the  widespread  utilization  of 
formal  requirements  specification  languages  will  not  be  the 
norm  for  many  years.  In  the  meantime,  suggestions  for 
formalizing  requirements  specification  include:  the  use  of 
compromise  notations  that  add  more  structure  than  that 
provided  by  natural  language;  tool  support  for  formal 
specification    development;     the    use    of    graphics    to    structure 
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specifications;     and    methods     that     focus     on     developing     the 
specification    in    an    incremental    fashion    [Som89]. 


1.1  Problem  Statement 
Several  proposals  have  been  discussed  that  purport  to 
improve  the  current  state  of  requirements  analysis  and 
specification.  However,  none  of  these  suggestions  have 
proven  effective  as  practical  solutions  to  the  software 
crisis.  It  is  this  author's  contention  that  the  lack  of 
success  is  not  due  to  any  inherent  deficiency  in  either  of 
the  suggestions,  but  rather,  it  is  because  each  solution 
addresses  only  a  fragment  of  the  problem  and,  in  so  doing, 
introduces  new  problems  that  must  be  dealt  with.  In 
essence,  the  practical  issues  of  how  to  incorporate  these 
ideas  into  the  existing  framework  of  software  development 
have    not    been    addressed. 

What  is  needed  is  a  comprehensive  solution  that 
combines  the  best  features  of  all  of  the  aforementioned 
suggestions  into  one  unified  approach  to  requirements 
analysis  and  specification.  This  dissertation  presents  a 
methodological  approach  for  requirements  analysis  and 
specification  that  utilizes  conceptual  modeling  to 
incrementally  develop  and  formally  specify  requirements. 
The  methodology  provides  a  graphical  formalism  for 
specification  within  an  object-oriented  framework.  The 
formal    requirements    specification    is    expressed    in    RML' . 
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1.2   Research  Agenda 

The  difficulties  involved  in  requirements  analysis  and 
specification  have  been  discussed,  and  a  number  of 
fragmentary  solutions  to  the  problem  have  been  presented. 
The  need  for  a  comprehensive  approach  that  integrates  the 
best  features  of  many  solutions  into  one  unified  methodology 
has  been  identified.  This  dissertation  develops  such  a 
requirements  methodology  based  on  conceptual  modeling. 

The  research  consisted  of  the  following  tasks: 

1.  Examining  requirements  methodologies, 
conceptual  modeling  approaches,  object-oriented 
approaches,  and  formal  requirements  specification 
languages ; 

2.  Developing  an  appropriate  methodological 
framework ; 

3.  Discovering  the  types  of  knowledge  represented 
in  conceptual  modeling  languages  and  identifying 
RML  as  a  formal  language  whose  semantics  represent 
the  basic  underlying  principles  of  conceptual 
modeling ; 

4.  Disambiguating,  evaluating,  and  simplifying 
the  syntax  and  semantics  of  RML,  and  defining  RML1 
which  integrates  these  simplifications  with  a  few 
extensions  to  strengthen  the  underlying  framework; 

5.  Analyzing  structural  dfd-based  requirements  to 
discover  the  types  of  knowledge  they  represent; 
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6.  Comparing  the  knowledge  contained  in  dfd-based 
requirements  with  the  knowledge  contained  in 
conceptual  models,  object-oriented  analysis 
approaches,  and  formal  requirements  specifications 
and  identifying  the  types  of  additional  knowledge 
necessary    at    the    specification    level; 

7.  Identifying  the  major  steps  of  a  requirements 
methodology  based  on  conceptual  modeling  that 
incrementally  develops  a  formal  requirements 
specification ; 

8.  Developing  strategies/techniques  for  eliciting 
and    representing    the    necessary    information; 

9.  Refining  the  major  steps  of  the  methodology  to 
incorporate  modeling  all  of  the  identified 
information; 

10.  Formally  defining  the  constructs  used  in  the 
methodology;    and 

11.  Developing  guidelines  for  checking  the 
consistency    of    the    developing    requirements. 


1.3  Dissertation  Outline 
This  dissertation  is  organized  into  five  chapters. 
Chapter  2  discusses  related  work  including  conceptual 
modeling  approaches,  object-oriented  approaches,  and 
existing  requirements  methodologies.  The  target  language, 
RML',  is  defined  in  Chapter  3  and  its  semantics  are 
discussed.        The     requirements     methodology    is    presented    in 
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Chapter  A.   A  summary,  the  contributions  of  this  thesis,  and 
directions  for  future  research  are  provided  in  Chapter  5. 


CHAPTER  2 
RELATED  WORK 


The  related  work  is  divided  into  the  following 
categories : 

1.  Traditional  methodologies  for  requirements 
analysis  and  specification; 

2.  Basic  concepts  of  conceptual  modeling; 

3.  Conceptual  modeling  and  object-oriented 
approaches ; 

4.  Requirements  methodologies  based  on  conceptual 
modeling;  and 

5.  Related  work  in  other  areas. 

2.1  Requirements  Methodologies 
The  most  widely  used  requirements  methodologies  are 
based  on  data  flow  diagrams.  These  include:  Structured 
Analysis  (SA)  [Dem79],  [War86],  [You89];  Structured  Systems 
Analysis  (SSA)  [Gan79];  and  Structured  Analysis  and  Design 
Technique  (SADT)  [Ros77a,  Ros77b]. 

The  varieties  of  SA  and  SSA  are  similar  and  should  be 
viewed  as  interpretations  of  the  same  technique.  They  are 
based  on  the  same  concepts:  data  flow  diagrams  (dfds) 
supported  with  data  dictionaries,  structured  English,  and 
decision  trees  and/or  tables.   The  later  versions  reflect 

12 
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extensions  of  the  model.   Ward  and  Mellor  [War86]  added 
control  information  to  be  able  to  describe  real-time 
systems,  and  Yourdon  [You89]  added  facilities  for  modeling 
data. 

SADT  looks  very  different  from  the  other  dfd  techniques 
because  it  uses  different  symbols,  but  actually  it  bears  a 
strong  resemblance  to  the  other  methods.  It  is  larger  in 
the  sense  that  there  are  more  language  features  (40  versus  4 
in  typical  dfds)  and  its  methodology  is  more  comprehensive, 
since  it  includes  management  information  such  as  personnel 
roles  and  reader  cycles. 

All  of  the  data  flow  diagram  modeling  techniques 
provide  an  excellent  facility  for  structuring  the  initial 
problem  analysis  and  understanding  the  functional 
decomposition  of  the  system.  Their  limitations  include 
being  informal  methods;  providing  a  single,  functional  view 
of  the  system  (except  for  [You89]);  giving  very  little 
emphasis  to  the  structure  of  the  data;  and  relying  heavily 
on  supporting  natural  language  text. 

Another  approach  focuses  more  on  the  communication 
aspects  of  the  requirements  definition  problem  than  on 
assisting  in  understanding  the  problem  being  analyzed.  This 
approach  utilizes  computer  technology  for  processing  and 
maintaining  all  information  obtained  during  requirements 
analysis  and  specification.  Two  examples  are  Problem 
Statement  Language/Analyzer  (PSL/PSA)  [Tei77]  and  Software 
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Requirements  Engineering  Methodology  (SREM)  [Alf77].  PSL/ 
PSA  consists  of  a  language  for  expressing  specifications 
(PSL)  and  an  analyzer  for  processing  the  descriptions  (PSA). 
SREM  applies  the  concepts  of  PSL/PSA  to  the  development  of 
real-time  systems.  It  utilizes  the  Requirements  Statement 
Language  (RSL)  [Bel77]  for  the  expression  of  software 
requirements. 

2.2  Basic  Concepts  of  Conceptual  Modeling 
The  seminal  work  on  conceptual  modeling  of  Smith  and 
Smith  [Smi77,  Smi80],  introduced  the  idea  of  using 
abstraction  to  understand  complex  systems.  Their  context 
was  the  area  of  database  design,  but  the  underlying 
principles  were  applicable  to  conceptual  modeling  in  any 
domain. 

The  premise  of  their  Semantic  Hierarchy  Data  Model  is 
that  humans  understand  complex  systems  by  creating 
abstractions  that  can  be  named  and  treated  as  a  whole. 
These  abstractions  allow  us  to  focus  on  the  details  of 
interest,  ignoring  other  peripheral  details.  They  are 
either  in  the  form  of  abstract  objects  or  abstract 
operations . 

When  modeling  systems,  we  use  three  abstraction 
mechanisms  for  describing  the  individuals  and  their 
interrelationships:  classification,  generalization,  and 
aggregation. 
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Classification  forms  new  objects  by  suppressing  the 
details  of  individual  instances  and  emphasizing  properties 
of  the  whole.  New  object  types  (classes)  are  formed  by 
collecting  instances.  Classification  corresponds  to  the  set 
theoretic  operation  of  'membership'  and  describes  the 
'instance-of '  relationship.  For  example,  classification 
would  allow  one  to  collect  the  instances  '{Jaue,  Bob,  Sue}' 
into   a    new   higher-order    type    called    'secretary.' 

Generalization  merges  existing  types  to  form  new  types. 
Individual  differences  between  subtypes  are  ignored  and 
common  traits  are  emphasized.  Generalization  corresponds  to 
the  set  theoretic  operation  of  'union'  and  describes  the 
'is-a'  relationship.  For  example,  the  existing  employee 
types  '{secretary,  teacher}'  can  be  generalized  to  form  the 
new  type  'employee.'  Generalization  implies  that  every 
instance  of  the  sub-type  is  an  instance  of  the  type.  Thus, 
every  instance  of  'teacher'  is  also  an  instance  of 
' employee .  ' 

Aggregation  forms  an  object  as  a  relationship  among 
other  objects.  It  suppresses  the  details  of  the  components 
and  emphasizes  the  details  of  the  relationship  as  a  whole. 
Aggregation  corresponds  to  the  set  theoretic  operation  of 
'cartesian  product'  and  describes  the  'is-part-of' 
relationship.        For     example,     consider     the     object     types 


person,  room, 


i      t 


hotel,'     and     'date.'        A     'reservation' 


bject     can     be     abstracted     from    the     relationship:     'a    person 
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reserves  a  room  in  a  hotel  for  a  date .  '  The  individual 
objects  (e.g.,  'room')  are  components  of  the  aggregate 
(i.e.,  'reservation').  An  instance  of  a  component  is  said 
to  be  an  attribute  of  an  instance  of  the  aggregate.  For 
example,  given  the  'reservation'  instance:  'Mary  reserves 
room  212  at  the  Sheraton  for  May  12th,'  then  'Mary'  is  the 
'person'    attribute    of    the    'reservation'    instance. 

Classification,  generalization,  and  aggregation  are  the 
basic  ways  we  have  of  structuring  information.  When  they 
are  repeatedly  applied  to  objects,  hierarchies  of  new 
objects  are  formed.  The  application  of  these  three 
mechanisms  forms  the  methodological  basis  for  conceptual 
modeling . 

There  are  three  primitive  operations  used  to  describe 
changes  in  the  model:  create,  destroy,  and  modify.  The 
create  operation  forms  an  individual,  implements  its 
membership  in  the  types  and  attribute  relationships 
specified  in  the  operation,  and  verifies  all  type 
constraints.  The  destroy  operation  removes  the  individual 
from  the  model  and  from  any  classes  and  attribute 
relationships  in  which  it  is  involved.  The  modify  operation 
may  involve  removals  or  additions  to  its  class  memberships 
and  attribute  relations.  It  may  be  applied  to  individuals 
(tokens)  or  types  (classes)  and  is  used  to  form  the 
classification  hierarchy.  To  continue  our  earlier  example, 
classification     can     be     applied     to     the     employee     types 
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'{secretary,     teacher}'     to     form     the     new     higher-order     type 
' { employee    type  }  .  ' 

To  use  these  primitive  operations,  a  predicate  language 
is  needed  to  specify  the  involved  individuals  in  terms  of 
their  attributes,  categories,  and  types.  Predicates  may  be 
used  with  these  operations  to  construct  function 
definitions.  These  functions  characterize  the  behavioral 
semantics  of  a  type  just  as  the  structural  semantics  are 
characterized    by    its    subtypes    and    component    types. 

These  basic  ideas  form  the  core  of  conceptual  modeling 
approaches.  Extensions  to  this  core  usually  include  time  as 
a  significant  factor.  For  example,  the  "application 
universe  of  discourse"  in  Gustafson  et  al.  is  defined  as 
consisting  of  a  "time  varying  set  of  entities"  [Gus82,  p. 
100].  Type  membership  as  well  as  attribute  values  and 
relationship  functions  may  vary  with  time.  Entities  have  an 
associated  existence  at  a  particular  time  't.'  The  notion 
of  an  event  is  used  to  include  dynamics  into  the  model. 
Events  play  the  same  roles  as  the  primitive  operations 
described    above. 

Because  of  the  importance  of  the  structural  components, 
conceptual  modeling  is  sometimes  equated  with  information 
modeling  (Conceptual  Information  Modeling  or  CIM). 
Alternatively,  conceptual  modeling  is  viewed  as  consisting 
of  two  sub-tasks:  information  modeling  together  with 
process    modeling. 
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Information  modeling  focuses  on  the  static  components 
and  is  referred  to  as  a  "snapshot"  since  it  models  a  slice 
of  reality  at  a  given  time.  This  approach  typically  avoids 
introducing  any  processing  type  information,  and 
consequently,  does  not  utilize  any  form  of  top-down 
functional  decomposition  or  data  flow-based  techniques  for 
analysis.  The  method  focuses  on  identifying  objects, 
attributes,  relationships,  subtypes/supert y pes ,  associated 
objects,  and  constraints  as  in  Bubenko  [Bub80]  and  Gustafson 
et  al.  [Gus82]  . 

The  process  model  depicts  the  dynamics  of  the  system. 
Processes,  activities,  or  events  are  used  to  depict  dynamic 
objects  that  affect  the  static  aspect  of  the  slice  of 
reality  being  modeled.  This  information  may  be  described  in 
a  state  transition  diagram  illustrating  the  various  states 
that  the  data  may  be  in  during  its  life-cycle,  the  events 
that  precipitate  state  changes,  and  the  actions  occurring  as 
a  result  of  those  state  changes  [Shl88],  [Yeh84]. 


2.3  Conceptual  Modeling  and  Object-oriented  Approaches 
Another  concept  that  is  frequently  linked  with 
conceptual  modeling  is  "object-oriented."  Object-oriented 
in  this  sense  means  "data-oriented  or  data-centered,"  i.e., 
that  modeling  the  data  is  of  primary  concern.  While  that  is 
certainly  true  of  an  object-oriented  view,  the  intended 
usage  implies  much  more  and  hinges  on  the  notion  of  an 
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object  itself.   As  Booch  [Boo83f  p.  424]  states: 

In  the  real  world,  an  object  is  simply  an  entity 
that  is  visible  or  otherwise  tangible;  we  can  do 
things  to  an  object  (like  throw  a  rock)  or 
objects  can  have  a  'life'  of  their  own  (for 
example,  as  in  a  stream  flowing  down  a 
mountainside).  In  our  software,  an  object  is  also 
any  entity  that  acts  or  can  be  acted  upon;  in  a 
sense,  objects  are  the  computational  resources  of 
our  system  that  parallel  (abstract)  the  objects 
from  the  real  world.  .  .  .  Objects  exist  in  time 
and  hence  can  be  created,  destroyed,  copied, 
shared,  and  updated. 

Thus,  an  object  is  a  data  abstraction  that  can  play  active 

and  passive  roles.    In  a  passive  role,  an  object  has 

operations  invoked  on  it  and,  in  an  active  role,  an  object 

can  invoke  operations  over  other  related  objects  [Bro82]. 

The  above  view  of  an  object  refers  to  the  concepts 
associated  with  object-oriented  approaches:  abstraction, 
information  hiding,  and  data  abstraction  [Boo83]. 
Additionally,  inheritance  is  also  typically  considered  an 
underlying  principle  of  object-oriented  approaches,  although 
it    may    not    be    a    "necessary"    component    [B0086]. 

Abstraction  refers  to  organizing  information  based  on 
classification,  generalization,  and  aggregation. 
Information  hiding  as  defined  by  Parnas  [Par72]  suggests 
decomposing  systems  into  components  that  hide  or  encapsulate 
design  decisions  about  abstractions.  Data  abstraction 
refers  to  defining  data  types  in  terms  of  the  operations 
that  apply  to  objects  of  the  type,  with  the  constraint  that 
the  values  of  such  objects  can  be  modified  and  observed  only 
by     the     use     of     the     operations     [0xf86].        Inheritance,     the 
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principle  of  receiving  properties  or  characteristics  from  an 
ancestor,  is  used  to  define  new  data  types  as  extensions  or 
restrictions  of  existing  types. 

Based  on  the  above  description  of  object-oriented, 
conceptual  modeling  as  previously  described  is  not  truly  an 
object-oriented  approach.  Conceptual  modeling  and  object- 
oriented  approaches  do  have  abstraction  and  inheritance  as 
common  characteristics.  However,  for  conceptual  modeling 
to  be  an  object-oriented  approach,  it  must  additionally 
incorporate  the  concepts  of  data  abstraction  and  information 
hiding.  This  further  implies  that  the  operations/processes 
must  be  encapsulated  and  associated  with  their  related 
objects  and,  hence,  cannot  be  dealt  with  separately  as  is 
typically  done  in  the  "snapshot"  plus  process  model 
approach. 


2.4  Conceptual  Modeling  of  Requirements 
The  work  discussed  in  this  section  reflects  the  use  of 
conceptual  modeling  as  the  methodological  basis  for 
requirements  analysis.  The  construction  of  a  model  for 
understanding  the  system  and  its  environment  is  viewed  as  a 
prerequisite  to  requirements  specification.  Abstraction 
plays  a  central  role  in  uncovering  the  objects,  functions, 
relationships,  constraints,  and  properties  of  the  developing 
system.  The  semantics  of  the  system  are  typically  defined 
within  a  temporal  framework. 
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The  methodology  for  conceptual  modeling  based  on  the 
Semantic  Hierarchy  Data  Model  of  Smith  and  Smith  [Smi80]  as 
described  earlier  consists  of  the  following: 

1.  identify  the  names  of  all  object  types  and 
functions  during  requirements  analysis; 

2.  use  classification,  generalization,  and 
aggregation  to  determine  type/instance,  object/ 
category,  and  object/component  relationships; 

3.  suppress  uninteresting  types,  categories,  and 
aggregate  objects  and  determine  important  naming 
conventions ; 

4.  identify  conditions  for  updating  object  types; 
and 

5.  specify  the  types,  categories,  components, 
functions,  and  attribute  relationships  of  each 
obj  ect . 

Although  this  was  a  methodology  for  producing  a  conceptual 
design  of  a  data  base,  it  is  representative  of  methodologies 
for  conceptual  modeling  of  requirements  [Bub80],  [Gus82]. 
Note  the  importance  given  to  modeling  the  structure  of  the 
data  vs  the  weak  attention  given  to  describing  the 
functions . 

Although  the  emphasis  on  data  structure  is  central  to 
all  conceptual  modeling  approaches,  some  methodologies  give 
more  attention  to  the  role  played  by  the  processes  than  do 
others.   For  example,  the  states  of  entities  and  events 
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causing    state    change    are    considered    important    in    Yeh    et    al. 
[Yeh84]    and    to    a    lesser    degree    in    Shlaer    and    Mellor    [Shl88]. 

One  novel  approach  that  treats  processes  and  entities 
uniformly  is  the  Requirements  Modeling  Language  (RML) 
[Gre8A].  In  this  approach  the  requirements  modeling  is 
viewed  as  a  conceptual  modeling  task,  and  a  formal 
requirements  specification  language  (RML)  is  defined  for 
expressing  the  model.  The  language  is  unique  in  that  it  is 
both  a  formal  requirements  specification  language  and  a 
conceptual  modeling  language.  The  semantics  of  RML  are 
based  on  fundamental  notions  of  conceptual  modeling  and 
accepted  properties  of  requirements.  A  methodological 
approach  is  given  that  utilizes  SADT  for  initial  problem 
analysis    and    RML    for    the    formal    specification. 

Viewed  as  a  conceptual  modeling  methodology  for 
requirements  specification,  the  RML  approach  inadequately 
addresses  the  pragmatic  aspects  of  how  to  integrate  the 
constructs  of  SADT,  conceptual  modeling,  and  RML  into  a 
unified  framework.  The  problems  associated  with 
transforming  an  initial  functional  decomposition  (the  SADT 
model)  into  an  object-oriented  description  (the  RML  model) 
are  overlooked,  although  the  fact  that  the  methodology 
results  in  uncharacteristic,  "simplistic"  RML  models  is 
noted . 2 


2Typical      object-oriented     RML     models     focus     on 
describing     a     system     in     terms     of     the     generalization 
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Another  problem  not  addressed  is  the  difficulty 
involved  in  describing  a  system  in  RML.  Since  RML  is  a 
formal  specification  language,  it  suffers  from  the  problems 
associated  with  formality  discussed  earlier.  To  simplify 
the  modeling  task,  the  methodology  should  assist  in 
incrementally    developing    the    specification. 

Greenspan's  work  on  RML  is  significant  because  it 
combines  the  notions  of  conceptual  modeling  and  formal 
specification  into  an  object-oriented  framework  for 
requirements  modeling.  The  associated  problems  stem  from  an 
inadequate    methodological    approach.        Solutions    to    these 

problems    are    investigated    in    Chapter    3. 

Kung  [Kun89]  also  utilizes  conceptual  modeling  as  the 
basis  for  requirements  modeling.  His  approach  is  visual 
and  formal  and  models  both  the  static  and  dynamic  aspects  of 
a  piece  of  reality  in  one  model.  He  models  process  behavior 
with  a  notation  borrowed  from  Petri  nets  and  relational 
calculus.  These  models  are  then  translated  into  Prolog 
programs  and  executed  (i.e.,  an  executable  specification  is 
produced)  . 

The  steps  involved  in  the  execution  of  a  process 
behavior  model  are  closely  related  to  the  semantics  of 
conceptual    modeling     and     RML.        Much     of     his    work    involves 


abstraction  (is-a  hierarchies)  to  utilize  inheritance. 
However,  RML  models  resulting  from  the  SADT/RML  methodology 
describe  functionally  decomposed  systems  based  on 
aggregation  (is-part-of  hierarchies),  and  consequently,  are 
not    object-oriented    and    do    not    utilize    inheritance. 
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defining  and  specifying  many  of  the  features  already  found 
in  conceptual  modeling,  RML,  and  various  other  requirements 
techniques.  Consequently,  it  appears  Kung  did  not  benefit 
from  the  efforts  of  others.  However,  due  to  these 
commonalities,  his  approach  is  consistent  with  the  goals  of 
this  research. 


2.5   Other  Related  Work 

The  position  taken  in  this  research  is  that  building  a 
requirements  model  is  parallel  to  constructing  a  knowledge 
base  about  some  slice  of  reality.  Both  requirements  models 
and  knowledge  bases  are  expected  to  be  natural  and  direct 
representations  of  the  knowledge  they  embody  so  that  they 
can  facilitate  communication  between  domain  experts,  system 
builders,  and,  ultimately,  system  users.  The  acquisition  of 
knowledge  from  human  experts  for  the  purpose  of  knowledge 
representation  demands  an  intense  understanding  of  the 
application  domain.  Understanding  the  problem  domain  is  an 
absolute  prerequisite  to  building  correct,  reliable  systems 
and  is  the  goal  of  requirements  analysis.  Thus,  knowledge 
representation  techniques  that  have  proved  useful  can  be 
utilized  for  requirements  modeling  [Bor85]. 

Semantic  networks,  a  knowledge  representation 
technique  introduced  by  Quillian  [Qui68]  as  a  model  of  human 
memory,  is  fundamental  to  this  research.  Semantic  networks 
represent  the  world  by  constructing  a  graph-like  model  of 
interrelated  objects.    These  objects  can  be  used  to 
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represent  any  category  of  conceptual  unit  of  information 
about  the  world  (for  example,  entities,  processes,  and 
constraints).  There  is  a  strong  emphasis  on  organization/ 
abstraction  principles,  with  'is-a'  hierarchies  often 
considered  synonymous  with  semantic  networks. 

The  dissertation  also  has  much  in  common  with  research 
in  the  database  and  information  system  areas.  The 
introduction  of  abstraction  principles  into  databases 
[Smi77]  and  of  conceptual  modeling  for  database  design 
[Smi80]  had  a  major  influence  on  the  framework.  The  entity- 
relationship  database  approach  [Che76]  proved  useful  for 
modeling  the  structure  of  objects,  and  the  introduction  of 
semantic  networks  into  databases  by  Roussopoulos  [Rou79]  was 
also  instructive. 

The  problems  associated  with  transforming  requirements 
expressed  in  dfds  into  object-oriented  design  (00D)  are 
addressed  by  Alabiso  [Ala88]  and  Coad  and  Yourdon  [Coa90], 
Alabiso  presented  a  transformation  from  dfds  to  00D,  which 
unfortunately,  was  far  too  simplistic.  It  maps  dfd  features 
(data,  processes,  terminals,  and  stores)  into  object- 
oriented  design/programming  components  (methods,  messages, 
and  classes  defined  in  the  Smalltalk-80  programming 
language).  The  additional  information  that  is  implicitly 
expressed  in  the  dfd  as  well  as  additional  information 
needed  to  clarify  and  solidify  the  intent  of  the  dfd  is 
ignored.    He  further  states  that  the  related  issues  of 
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organization/abstraction    principles     (which    are     fundamental 
to    00D)     are     truly     "design-time    tasks"     and    should    not    be 
dealt    with    by    a    development    methodology. 

The  work  of  Coad  and  Yourdon  [Coa90]  is  most  related  to 
our  goals.  They  address  the  need  for  an  object-oriented 
analysis  (00A)  methodology  as  a  prequisite  to  00D.  Their 
methodology  emphasizes  abstraction  mechanisms  and  data 
abstraction  as  does  ours,  but,  like  Alabiso,  they  introduce 
design  components  during  the  analysis  phase.  By  focusing  on 
the  00D  components  methods  and  messages,  they  force  the 
analyst  to  make  design  decisions.  Their  methodology 
concentrates  on  the  data  modeling  aspects,  as  is  typically 
done  in  OOA/OOD  approaches,  and  neglects  the  dynamic 
aspects.  Their  methodology  has  no  formal  underpinnings,  and 
the  results  have  to  be  respecified  in  a  natural  language 
requirements  specification.  However,  due  to  the  common 
framework,  their  approach  serves  to  reinforce  this  research. 
Further,  since  they  only  model  the  static  aspects  of 
objects,  their  diagrams  are  easier  to  comprehend  than  those 
resulting    from    our    methodology. 

This  chapter  discussed  related  work  including 
traditional  methodologies  for  requirements  analysis  and 
specification,  the  basic  concepts  of  conceptual  modeling, 
object-oriented  and  conceptual  modeling  approaches, 
requirements  methodologies  based  on  conceptual  modeling,  and 
related    work    in    other    areas.       The    next    chapter    presents    the 
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framework     of     our     approach     and     the     formal     specification 
language    that    is    the    target    of    our    methodology. 


CHAPTER    3 
THE    TARGET    LANGUAGE 


3.1      The    Framework 


A  conceptual  modeling  approach  is  to  be  taken  toward 
developing  a  methodology  for  requirements  modeling  that 
provides  a  graphical  formalism  for  specification.  The 
methodology  utilizes  a  layered,  incremental  approach  to 
development  within  an  object-oriented  framework.  The 
methodology  addresses  both  requirements  analysis  and 
requirements  specification  by  providing  a  formal  definition 
of  the  constructs  identified  during  the  development  process. 
The    formal    requirements    specification    is    expressed    in    RML' . 

The  basic  assumption  underlying  the  methodology  is  that 
humans  use  abstraction  mechanisms  (classification, 
generalization,  and  aggregation)  for  understanding  complex 
systems.  Therefore,  those  same  abstractions  should  be  used 
for  organizing  and  identifying  the  requirements  of  a  system. 
Furthermore,  applying  those  abstractions  within  a  framework 
that  emphasizes  information  hiding,  data  abstraction,  and 
inheritance  results  in  requirements  that  are  reliable, 
modifiable,    and    easy    to    understand. 

Object-oriented  approaches  and  conceptual  information 
modeling    approaches    decompose    a    system    based     on    the     'is-a' 
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hierarchical    structure    of    the     data.        The    models    identify 
objects,    attributes,    constraints,    types/subtypes,    associated 
objects,     and     relationships.        Processes    are    of    secondary 
importance    in    both   cases. 

Object-oriented  approaches  specify  processes  in  terms 
of  the  object-oriented  design/programming  components: 
methods  and  messages.  Methods  are  the  processes  that  apply 
to  an  object.  Messages  are  sent  from  one  object  to  another 
to  activate  processes  and  define  the  interface  between 
obj  ects. 

Top-down  functional  decomposition  approaches  view  a 
system  in  terms  of  the  'is-part-of'  hierarchical  structure 
of  the  functional  components.  The  model  consists  of 
processes,  subprocesses ,  data  flows  into  and  out  of  the 
processes,  and  external  process  interfaces.  The  modeling  of 
the  data  is  of  secondary  importance  and  is  usually  described 
textually    in    a    data    dictionary    rather    than    within    the    model. 

Functional  decomposition  methods  result  in  systems  that 
are  difficult  to  maintain  due  to  their  early  emphasis  on 
functions.  Functions  tend  to  change  over  time  which 
requires  changing  the  system.  On  the  other  hand,  existing 
object-oriented  analysis  techniques  are  too  design  oriented. 
They  force  the  requirements  analyst  to  make  design  decisions 
since  the  same  constructs  utilized  at  the  design  level 
(methods  and  messages)  must  be  specified  at  the  requirements 
level . 
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Current  analysis  approaches  are  either  function- 
oriented  or  object-oriented  and  force  the  analyst  to  select 
one  of  these  views  as  the  overall  view  of  the  system. 
However,  since  all  systems  consist  of  both  data  and 
processes,  and  since  the  goal  of  requirements  modeling  is  to 
understand  the  complete  system,  the  requirements  methodology 
should  assist  in  viewing  a  system  from  both  perspectives. 
This  would  shed  the  most  light  on  the  innerworkings  of  the 
system,  and  consequently,  result  in  more  clearly  defined 
requirements . 

This  research  incorporates  an  object-oriented 
framework  based  on  object-oriented  concepts  rather  than 
object-oriented  design/programming  constructs.  Processes 
are  identified  with  their  associated  objects  (i.e.,  data 
abstraction)  and  abstraction  is  used  to  define  both  objects 
and  processes  (i.e.,  information  hiding  and  inheritance). 
The  framework  integrates  concepts  from  object-oriented  and 
functional     decomposition    approaches    into    one    methodology. 

The  methodology  utilizes  the  three  abstraction 
mechanisms  to  model  the  three  types  of  objects:  entities, 
processes,  and  constraints.  Thus,  there  are  'is-a' 
hierarchies,  'is-part-of'  hierarchies,  and  '  instance-of ' 
hierarchies  for  entities,  processes,  and  constraints.  These 
hierarchies    describe    the    structure    of    the    model. 

Each  individual  described  in  the  model  is  an  instance 
of    some     class.        Data    abstraction    is     used     to     define     these 
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classes.  Thus,  objects  are  defined  in  terms  of  the 
relationships/processes  that  apply  to  instances  of  the 
class.  These  relationships  relate  instances  of  the  class  to 
objects  of  all  three  types.  Also,  the  instances  of  the 
class  can  be  accessed  only  by  those  identified 
relationships/processes. 

The  graphical  presentation  is  motivated  by  the  "one 
picture  is  worth  ten  thousand  words"  idea.  Graphics  help 
the  user  (and  analyst)  understand  what  is  being  developed  by 
providing  something  to  be  internalized  and  compared  to  the 
user's  existing  internal  model.  This  comparison  cannot  be 
made  with  any  of  the  static,  formal  notations  currently  in 
use  for  the  specification  of  requirements  [Yeh84], 

The  components  of  the  methodology  are  based  on  familiar 
techniques/concepts.  The  dynamic  nature  of  the  system  is 
modeled  with  a  simplified  dfd.  The  structure  of  entitites, 
processes,  and  constraints  is  defined  using  a  notation  based 
on  Chen's  [Che76]  entity-relationship  diagram.  Processes 
are  specified  based  on  standard  precondition/postcondition 
concepts.  The  dynamics  are  refined  by  adding  annotations  to 
specify  data  flow  branches/ j oins  and  function  activation 
rules  [Mar88]. 


3.2   The  Target 
Requirements  Modeling  Language  (RML)  developed  by 
Greenspan  [Gre84]  is  a  conceptual  modeling  language  and  a 
formal  requirements  specification  language.    Due  to 
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ambiguities  in  the  syntax  and  semantics  of  RML ,  a  simplified 
version  has  been  defined  (called  RML'  due  to  its  proximity) 
and  is  used  in  the  methodology. 

The  methodological  components  are  formally  defined  in 
RML'  and  the  result  of  the  methodology  is  a  formal 
requirements  specification  expressed  in  RML'.  The 
semantics  of  RML'  are  integrated  into  the  methodology  and 
are  significant  as  they  represent  the  basic  underlying 
principles  of  conceptual  modeling. 

In  general,  the  semantics  of  RML  and  RML'  are  very 
similar.  However,  some  significant  semantic  distinctions  do 
exist  between  the  two  languages.  These  are  discussed  in  the 
overview  of  the  semantics  of  RML'  that  follows.  The  RML' 
language  definition  is  given  in  Appendix  A. 

RML1  provides  an  object-oriented  requirements  model  in 
which  all  information  is  represented  by  objects.  The 
objects  are  inter-related  by  properties  and  grouped  into 
classes  (and  me t ac 1  as se s )  .  There  are  three  types  of 
obj  ects : 

1.  entities:   the  objects  in  the  world, 

2.  processes:    the  actions  that  cause  change  in 
the  world,  and 

3.  constraints:    what  should  be  true  in  the 
world . 

Objects  within  RML'  are  related  to  other  objects  by 
properties  (relationships).   Properties  have  three  pieces  of 
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information: 

1.  subject, 

2.  attribute  (also  known  as  the  property  name), 
and 

3.  value. 

There     are     two     kinds     of     properties:        factual     and 
definitional.         Factual     properties     express     factual 
information    about    individual    objects    (tokens)    or    classes. 
EXAMPLE:       <    john-smith,    age,    23    > 

In    this    example,     'john-smith1     is    the    subject,     'age'    is 
the     attribute,     and     f23'     is     the     value.        Definitional 
properties    specify    generic    information    that    pertains    to    each 
of    the    instances    (or    tokens)    of    a    class    (or    metaclass). 
EXAMPLE:       (    PERSON,    age,    AGE_VALUE    ) 

In  this  example  'PERSON'  is  the  subject,  'age'  is  the 
attribute,  and  'AGE_VALUE*  is  the  value.  A  factual 
property  corresponds  to  each  definitional  property  of  a 
class  (or  metaclass).  Classes  (or  metaclasses)  induce 
factual  properties  of  their  instances.  In  the  above 
examples,  'john-smith'  is  an  instance  of  the  class  'PERSON,' 
'PERSON'  has  the  definitional  property  'age,'  therefore, 
'john-smith'  must  have  an  induced  factual  property  'age' 
whose    value    '23'    is    an    instance    of    the    class    ' AGE_VALUE. ' 

Definitional  properties  are  grouped  into  categories. 
Each  object  type  has  a  set  of  associated  definitional 
property     categories.        For     a     complete     listing     of     these 


34 
definitional  property  categories  see  Figure  1. 

RML'  supports  the  three  abstraction  principles 
associated  with  conceptual  modeling:  classification, 
aggregation,  and  generalization.  The  framework  of  classes, 
properties,  and  abstraction  principles  applies  uniformly  to 
all  three  kinds  of  objects:  entities,  processes,  and 
constraints . 

Like  other  conceptual  modeling  languages,  RML'  has  a 
temporal  framework.  Time  is  viewed  as  an  infinite  and 
dense  sequence  of  time  points.  Every  event  has  an 
associated  start  and  end  point;  constraints  are  true  at  a 
given  time  point;  and  the  value  of  an  object's  properties  as 
well  as  its  membership  in  a  class  is  evaluated  with  respect 
to  time.  Property  categories  are  used  to  specify  temporal 
constraints  and  to  specify  default  times  when  properties 
will  be  evaluated. 

An  object  is  defined  on  one  of  four  classification 
levels:  token  (level  0),  class  (level  1),  metaclass  (level 
2),  and  metametaclass  (level  3).  A  token  is  an  instance  of 
one  or  more  classes  but  has  no  instances  of  its  own;  a  class 
is  an  instance  of  one  or  more  metaclasses  and  has  tokens  as 
instances;  a  metaclass  is  an  instance  of  one  or  more 
me t ame t a c 1  as s e s  and  has  classes  as  instances;  a 
metametaclass  has  metaclasses  as  instances. 

For  organizing  the  classes,  RML'  provides  a  number  of 
built-in  classes  and  metaclasses.   For  simplification,  these 
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Definitional  property  categories  for  an  ENTITY: 

necpart      a  non-null  ENTITY  that  is  a  permanent  attribute 

of  an  instance 
association  an  associated  ENTITY  that  might  change  over  time 
component    an  ENTITY  that  is  a  component  of  an  instance 
invariant    a  CONSTRAINT  that  is  always  true  of  the 

instance 
initcond     a  CONSTRAINT  that  is  true  when  an  object  becomes 

an  instance  of  the  class 
finalcond    a  CONSTRAINT  that  is  true  at  the  time  an  object 

ceases  to  be  an  instance  of  the  class 
producer     a  PROCESS  that  produces  the  instance 
consumer     a  PROCESS  that  consumes  the  instance 
modifier     a  PROCESS  that  modifies  the  instance 
constraint   a  CONSTRAINT  that  specifies  additional 

conditions  about  the  instance 

Definitional  property  categories  for  a  PROCESS: 

input        an  ENTITY  participating  in  the  PROCESS  and 

taken  from  the  given  property  value  class 
output       an  ENTITY  inserted  into  the  given  property  value 

class  by  this  process 
control      an  ENTITY  participating  in  the  PROCESS  but  not 

removed  from  the  given  property  value  class  by 

this  PROCESS 
precond      a  CONSTRAINT  that  must  be  true  at  the  start  time 
postcond     a  CONSTRAINT  that  must  be  true  at  the  end  time 
actcond      a  CONSTRAINT  which,  if  it  becomes  true  at  any 

point,  causes  an  associated  instance  of  the 

PROCESS  to  begin  at  that  point 
stopcond     a  CONSTRAINT  which,  if  it  becomes  true,  causes 

the  PROCESS  instance  to  stop  at  that  point 
component    a  PROCESS  that  must  occur  in  order  for  the 

instance  to  occur 
constraint   a  CONSTRAINT  that  specifies  additional 

conditions  that  must  be  true  in  order  for  the 

instance  to  occur 

Definitional  property  categories  for  a  CONSTRAINT: 

argument     an  ENTITY  that  is  an  argument  of  the  CONSTRAINT 
part         a  CONSTRAINT  that  is  true  when  subject  is  true 
suffcond     a  CONSTRAINT  that  is  a  sufficient  condition  for 

the  instance  to  be  true 
defn         a  CONSTRAINT  class  every  instance  of  which  gives 

a  necessary  and  sufficient  condition  for  subject 

to  be  true 
constraint   a  CONSTRAINT  expression  with  a  non-null  value 

Figure  1.   RML'  Definitional  Property  Categories 


36 
built-in  objects  have  been  kept  to  a  minimum.  Our  modeler 
is  provided  with  the  built-in  metaclasses:  CLASS,  which 
contains  all  classes,  PROCESS_CLASS ,  ENTITY_CLASS ,  and 
CONSTRAINT_CLASS.  To  further  describe  the  classification 
hierarchy,  the  following  built-in  me  t  ame  t  ac  1  as  s  e  s  are 
provided:  PROCES S_MET ACL AS S ,  ENTITY_METACLAS S ,  and 
CONSTRAINT_METACLASS . 

Ambiguities  found  in  the  semantics  and  syntax  of  RML 
were  reflective  of  underlying  structural  problems  that 
needed  to  be  dealt  with  to  solidify  the  framework  of  RML'. 
Many  of  the  identified  problems  focused  on  the  intended 
semantics  associated  with  using  the  built-in  classes/ 
metaclasses  and  the  difference  between  'in'  (instance)  and 
'is-a.' 

The  'is-a'  relationship  has  been  used  to  describe  many 
different  types  of  relationships  [Bra83],  [Woo75],  In  many 
schemes  that  use  'is-a,'  the  relationship  is  used  to  say 
both  that  an  object  is  an  instance  of  a  class  (e.g.,  Sue  is 
a  teacher)  and  that  one  class  is  a  subclass  of  another 
(e.g.,  a  teacher  is  a  person).  The  first  case  is  an 
example  of  classification  and  is  denoted  in  RML  (and  RML') 
by  the  'in'  relationship.  The  second  case  is  an  example  of 
generalization  and  is  the  only  intended  usage  of  the  'is-a' 
relationship  used  in  RML  (and  RML'). 

Recall  that  definitional  properties  specify  generic 
information  that  pertains  to  each  of  the  instances  of  a 
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class  or  metaclass.   Factual  properties  express  factual 

information  about  individual  objects  or  classes. 

There  are  three  constraints  that  are  central  to  the 

conceptual  modeling  framework  of  RML  and  RML'  that  describe 

the  semantics  of  the  above  ideas.   They  are  [Gre84f  p.  13]: 

Property  induction  constraint  —  Every  instance  of 
a  class  or  metaclass  has  an  induced  factual 
property  corresponding  to  each  definitional 
property  of  the  class  with  a  value  that  is  an 
instance  of  the  definitional  property  value  or 
null. 

Extensional  ISA  constraint  --  If  C  ISA  D  then 
every  instance  of  C  is  an  instance  of  D. 

Intentional  ISA  constraint  --  If  C  ISA  D  then 
every  definitional  property  i  of  D  is  also  a 
definitional  property  of  C,  and  furthermore,  the 
value  of  property  i  for  C  ISA  the  value  for 
property  i  of  D. 

To  clarify  the  meaning  of  the  above  constraints, 

consider  the  following  examples: 

Let  PERSON_CLASS  be  a  metaclass  with  properties: 
cardinality  and 
a  v  e  r  a  g  e_a  g  e . 

Let  PERSON  be  a  class  with  properties: 
name  and 
s  o  c  i  a l_s  e  c  u  r  i  t  y_#  . 

Let  STUDENT  be  a  class  with  properties: 
grade_level  and 
g  r  a  d  e_p  o  i  n  t_a  v  e  r  a  g  e . 

The  statement:   'PERSON  in  PERSON_CLASS '  means  PERSON 

is  an  instance  of  PERSON_CLASS ,  and  therefore,  by  the 

property  induction  constraint,  has  factual  properties 

induced  for  each  definitional  property  of  PERSON_CLASS . 
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Thus,  the  class  PERSON  has  values  for  'cardinality'  and 
' average_age. ' 

The  statement:  'STUDENT  isa  PERSON'  means  every 
instance  of  STUDENT  is  also  an  instance  of  PERSON,  and  the 
definitional  properties  of  PERSON  are  also  definitional 
properties  of  STUDENT,  inherited  from  PERSON.  So  STUDENT 
has  properties  'name,'  ' social_security_# ,  '  ' grade_level ,  ' 
and  '  grade_point_average '  and  all  instances  of  STUDENT  have 
factual  properties  induced  for  each  of  these  properties. 

In  cases  where  there  are  no  required  metaclass 
properties  (e.g.,  no  need  for  class  cardinality),  RML  allows 
the  use  of  a  built_in  metaclass.  Thus,  instead  of  defining 
a  metaclass  in  the  above  example,  one  could  use  the  built_in 
metaclass  ENTITY_CLASS  and  say  'PERSON  in  ENTITY_CLASS .  ' 
Alternatively,  one  could  say  'PERSON  isa  ENTITY_CLASS .  ' 
Both  usages  occur  in  the  RML  language  description  and  are 
syntactically  correct.  However,  no  attempt  was  made  by 
Greenspan  to  distinguish  between  the  two  statements.  Since 
the  distinction  between  these  statements  is  not  obvious,  and 
the  resulting  semantic  implications  are  even  more  obscure, 
this  required  disambiguation. 

Being  an  instance  of  a  built_in  metaclass  (or  class) 
(e.g.,  'PERSON  in  ENTITY_CLAS S ' )  means  that  factual 
properties  are  induced  for  each  definitional  property  of  the 
metaclass  (or  class).  But  a  built_in  class  (or  metaclass) 
has  no  definitional  properties,  therefore  no  factual 
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properties  are  induced.  By  the  'is~a'  constraints,  'PERSON 
isa  ENTITY_CLASS'  means  every  instance  of  PERSON  is  an 
instance  of  ENTITY_CLASS  and  every  definitional  property  of 
ENTITY_CLASS  is  a  definitional  property  of  PERSON.  Again, 
since  built_in  classes  (and  metaclasses)  have  no 
definitional  properties,  'PERSON  isa  ENTITY_CLASS '  adds  no 
new  information  to  the  definition  of  PERSON. 

In  both  cases,  no  new  properties  are  induced  or 
inherited.  However,  the  two  statements  are  not  equivalent. 
Recall  that  objects  are  defined  on  one  of  four 
classification  levels.  This  classification  level  determines 
the  level  of  instances  of  the  object.  'A  in  B'  means  that 
if  B  is  level  n,  then  A  is  level  n-1.  'Is-a'  related 
objects  have  the  same  classification  level  (see  Figure  2). 

The  statement  'PERSON  in  ENTITY_CLASS '  implies  that 
PERSON  is  an  instance  of  a  metaclass,  which  is  a  class. 
Instances  of  PERSON  are  tokens.  On  the  other  hand,  'PERSON 
isa  ENTITY_CLASS'  implies  that  PERSON  is  a  metaclass. 
Instances  of  PERSON  are  classes.  Thus  there  are  semantic 
distinctions  between  the  two  statements.  To  complicate  this 
even  a  bit  more,  RML  also  allows  'PERSON  in  ENTITY_ 
METACLASS'  which  means  that  PERSON  is  an  instance  of  a 
metametaclass ,  which  is  a  metaclass.  Again,  there  would  be 
no  factual  properties  induced  and  thus,  this  statement 
would  have  the  same  effect  as  'PERSON  isa  ENTITY  CLASS.' 
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Figure  2:   Classification  Levels 
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The  above  illustrates  the  need  for  some  semantic 
distinctions.  Since  'is-a'  represents  the  generalization 
abstraction,  'is-a'  related  objects  should  reflect  some  type 
of  specialization  occurring.  That  cannot  be  possible  if  the 
generalization  is  a  built_in  class  (or  metaclass). 
Alternatively,  the  'in'  relationship  represents  the 
classification  abstraction  which  is  used  to  describe  a 
relationship  between  objects  existing  at  different 
classification  levels.  That  is  precisely  what  is  occurring 
in  any  relationship  involving  a  built_in  class  (or 
metaclass).  Therefore,  a  constraint  was  added  to  RML' 
specifying  that  built_in  classes  and  metaclasses  may 
participate  in  'in'  relationships  but  may  not  participate  in 
'is-a'    relationships. 

Other  related  structural  problems  occurring  in  RML 
concern  the  semantics  involved  with  'in'  and/or  'is-a' 
relationships  involving  more  than  two  objects.  Again,  these 
relationships  are  used  in  the  RML  language  description  and 
are  syntactically  correct,  but  are  semantically  ambiguous. 
More  importantly,  they  also  appear,  perhaps  inadvertently, 
in  the  classification/generalization  diagrams  resulting  from 
the  proposed  methodology.  Consequently,  they  must  be 
precisely  defined.  The  following  properties  were  identified 
and    added    to   RML'  : 

1.       'is-a'      is     a     transitive     relationship     and 

definitional     properties     should     be     inherited 
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accordingly . 

2.  'in'  is  not  a  transitive  relationship  and 
factual  properties  may  be  induced  only  for  an 
instance  of  a  class  or  metaclass. 

3.  If  A  isa  B  and  B  isa  C  then  A  isa  C  and  A,  B, 
and  C  are  'is-a  related.' 

4.  If  A  is  an  instance  of  B,  then  all  objects 
'is-a  related'  to  A  are  also  instances  of  B  and 
have  induced  factual  properties  corresponding  to 
each  definitional  property  of  B. 

See  Appendix  B  for  details. 

The  most  significant  difference  between  RML  and  RML'  is 
due  to  the  framework  of  the  methodology  and  our  desire  for 
uniformity.  Specifically,  the  fact  that  the  framework 
integrates  an  analysis  technique  based  on  functional 
decomposition  with  an  object-oriented/conceptual  modeling 
approach  requires  a  synthesis  of  the  two  opposing  views. 
Furthermore,  the  methodology  utilizes  the  three  abstraction 
mechanisms  to  uniformly  model  the  three  types  of  objects. 

Recall  that  functional  decomposition  approaches  view  a 
system  in  terms  of  the  'is-part-of'  hierarchical  structure 
of  the  processes.  Object-oriented  approaches  and 
conceptual  modeling  approaches  decompose  a  system  based  on 
the  'is-a'  hierarchical  structure  of  the  data.  The  analysis 
portion  of  the  methodology  results  in  'is-a'  hierarchies  and 
'is-part-of'  hierarchies  for  both  processes  and  data.   The 
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problem  occurs  when  trying  to  map  those  two  views  onto  RML, 
which,  being  a  conceptual  modeling  language,  supports 
decomposition  based  on  the  generalization  ('is-a')  and 
classification  ( ' instance-of ' )  abstraction  mechanisms. 

RML  makes  an  attempt  to  support  'is-part-of ' 
decompositions  via  the  part  property  categories  for  entities 
and  processes.  For  processes  a  part  property  is  a  process 
that  must  occur  in  order  for  the  instance  to  occur.  That  is 
precisely  what  it  should  be,  but  the  problem  is  that  one 
cannot  hierarchically  decompose  a  system  based  on  the  'is- 
part-of'  structure  of  the  processes  using  only  this  one 
property  category. 

For  entities  a  part  property  is  a  non-null  entity  that 
is  a  component  of  an  instance.  These  are  considered 
permanent  attributes  because  their  values  are  fixed  over  the 
life-time  of  the  instance.  For  example,  a  PERSON  might  have 
part  properties  'name'  and  ' social_secur i ty # .  '  Again, 
there  is  no  way  to  hierarchically  decompose  entities  based 
on  their  aggregation  structure  using  only  this  one  property 
category . 

To  remedy  this  situation,  RML'  has  been  defined  with 
the  following  semantic  distinctions: 

1.   The  'part-of'  relationship  has  been  added  to 

allow  for  hierarchical  decomposition  based  on 

aggregation. 
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EXAMPLE:   EXAMINE  part-of  EVALUATE 

Given  that  'EVALUATE'  is  defined  with  'EXAMINE'  as 
a  component,  the  'part-of'  relationship  allows  us 
to  illustrate  their  hierarchical  relationship  by 
defining  'EXAMINE'  as  'part-of'  the  aggregate 
'EVALUATE.' 

2.  The  part  property  category  for  processes  was 
replaced  with  component  and  was  defined  to  be  a 
PROCESS  that  must  occur  in  order  for  the  instance 
to  occur. 

EXAMPLE:   EVALUATE  in  PROCESS_CLASS  with 
component 

examine:   EXAMINE 

This  example  illustrates  that   'EVALUATE*  has 

'EXAMINE'  as  a  component.   This  definition  of 

'EVALUATE'  requires  that  'EXAMINE'  be  defined  as 

'part-of*  'EVALUATE'  due  to  their  hierarchical 

relationship . 

3.  The  component  property  category  for  entities 
was  added  and  defined  to  be  an  ENTITY  that  is  a 
component  of  an  instance. 

4.  The  part  property  category  for  entities  was 
replaced  with  necpart  and  defined  to  be  a  non-null 
ENTITY  that  is  a  permanent  attribute  of  an 
instance . 
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5.   Two  additional  constraints  that  are  central  to 
the  framework  of  RML '  are  needed  to  describe  the 
semantics  of  the  above  ideas.   They  are: 

Extensional  PART-OF  constraint  —  If  C  PART-OF  D 
then  every  instance  of  C  is  a  component  of  an 
instance  of  D. 

Intentional  PART-OF  constraint  —  If  C  PART-OF  D 
then  every  component  i  of  C  is  also  a  component  of 
D,  and  furthermore,  the  value  of  every  component  i 
of  C  is  PART-OF  the  C  value  for  D. 

EXPLANATION:  The  first  constraint  is  specifying 
the  relationship  between  'part-of'  and  component . 

EXPLANATION:  The  second  constraint  is  specifying 
that  components  and  their  values  are 
hierarchically  related.  It  further  states  that 
components  are  upwardly  inherited  by  their 
aggregates . 

EXAMPLE:   D  with 

component 
a:   A 
b:   B 
c:   C 

C  part-of  D  with 
component 
r:   R 
s:   S 

Thus,  D  has  components:  a,  b,  c,  r,  s;  and 

R  part-of  C,  and  S  part-of  C. 


46 
6.   If  C  part-of  D  and  B  isa  D  then  C  part-of  B, 
and  furthermore,  C  is  part-of  all  objects  isa 
related  to  D. 

EXAMPLE:   Continuing  the  above  example,  add: 

X  isa  Y 
Y  isa  Z 
Z  isa  D 

Then,  C  part-of  X,  C  part-of  Y,  C  part-of  Z;  and 
X,  Y,  and  Z  all  have  components:   a,  b,  c,  r,  s. 

This  chapter  discussed  the  framework  of  our  approach 
and  the  syntax  and  semantics  of  the  target  language. 

Language  extensions  were  presented  as  clarifications  to 
enhance  the  semantic  contents  of  the  methodology.  The  next 
chapter  presents  the  methodology. 


CHAPTER  4 
THE  METHODOLOGY 


This  chapter  presents  the  requirements  methodology. 
The  major  steps  are  identified,  strategies  for  refining  the 
model  are  explored,  and  techniques  for  checking  the 
consistency  of  the  developing  model  are  examined.  To 
illustrate  the  methodology,  one  example  is  developed 
throughout  this  chapter.  The  sample  domain  is  a  hospital 
from  the  patient/processing  perspective  (as  opposed  to  other 
perspectives  such  as  management/personnel,  patient  services, 
etc.).  Please  note  that  there  is  nothing  intrinisic  about 
the  particular  domain  selected  that  links  it  to  the 
methodology,  it  is  just  used  for  illustrative  purposes.  The 
methodology  is  applicable  to  requirements  modeling  in  any 
domain.   Specific  limitations  are  discussed  in  Chapter  5. 

The  methodology  consists  of  the  following  nine  steps: 

1.  Identify  objects  and  processes, 

2.  Model  system  dynamics, 

3.  Model  structure  of  entities, 

4.  Model  structure  of  processes, 

5.  Refine  entities, 

6.  Refine  processes, 

7.  Annotate  to  refine  dynamics, 
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8.  Specify    constraints,    and 

9.  Write    formal    requirements    in    RML'. 

A    brief    overview    of    each    of    these    steps    follows. 

1  .  Identify  objects  and  processes.  This  step  consists 
of  listing  the  major  objects  and  processes  in  the  system 
being  developed.  Objects  and  processes  should  be  clustered 
into    aggregation    hierarchies    and    specialization    hierarchies. 

2.  Model  system  dynamics.  This  step  models  the 
dynamics  of  the  system  using  a  simplified  dfd. 
Decomposition  of  both  processes  and  data  based  on  their 
aggregation  structures  occurs  at  this  level.  'Is-part-of' 
hierarchies  for  processes  are  identified  as  in  any 
functional  decomposition.  The  data  is  also  decomposed 
("leveled"  in  SA  terminology)  as  in  all  dfd-based 
techniques . 

3.  Model  structure  of  entities.  A  modified  entity- 
relationship  diagram  (erd)  is  used  to  model  the  structure  of 
the  entities.  Generalization  is  used  to  model  class/ 
subclass  entity  relationships  in  an  Entity  Generalization 
Structure  diagram.  Aggregation  is  used  to  model  object/ 
component  entity  relationships  in  an  Entity  Aggregation 
Structure    diagram. 

4.  Model  structure  of  processes.  A  modified  erd  is 
used  to  model  the  structure  of  the  processes. 
Generalization  is  used  to  model  class/ subclass  process 
relationships    in    a    Process    Generalization    Structure    diagram. 
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Aggregation     is     used     to     model     object/component     process/ 
subprocess    relationships    in    a    Process    Aggregation    Structure 
diagram. 

5.  Refine  entities.  This  step  consists  of  two 
subtasks:  identify  related  objects  and  processes;  and 
specify  class/metaclass  refinement.  The  first  subtask 
identifies  associated  objects,  necessary  part  objects,  and 
related  processes.  The  second  subtask  utilizes  the 
classification  abstraction  mechanism  to  specify  'in'  related 
class/metaclass  instances.  Class  names  of  the  property 
values  for  all  previously  defined  properties  are  specified, 
and  specialized  property  values  are  given  for  subclasses  as 
appropriate.  Any  additional  attributes  associated  with 
subclasses  are  identified.  This  information  is 
incrementally  added  to  the  entity  structure  diagrams 
obtained    in    step    3. 

6.  Refine  processes.  This  step  consists  of  two 
subtasks:  identify  input,  output,  and  associated  objects; 
and  specify  class/metaclass  refinement.  The  first  subtask 
involves  specifying  information  in  the  process  erds  that  was 
previously  identified  on  the  dfd  to  emphasize  their 
semantics  in  the  conceptual  modeling  language.  The  second 
subtask  utilizes  the  classification  abstraction  mechanism 
to  specify  'in'  related  class/metaclass  instances.  Class 
names  of  the  property  values  for  all  previously  defined 
properties    are    specified    and    specialized    property    values    are 


50 
given  for  subclasses  as  appropriate.   Additional  properties 
associated  with  subclasses  are  identified.    This 
information  is  incrementally  added  to  the  process  structure 
diagrams  obtained  in  step  4. 

7.  Annotate  to  refine  dynamics.  This  step  identifies 
information  that  is  needed  to  interpret  the  meaning  of  the 
dynamic  model  obtained  in  step  2.  It  consists  of  three 
subtasks:  model  internal  process  behavior;  model  external 
process  behavior;  and  model  entity  behavior.  The  internal 
process  behavior  is  modeled  by  identifying  triggering 
conditions  and  pre-/ postconditions .  The  external  process 
behavior  is  modeled  by  specifying  constraints  describing  the 
life-cycle  of  entities,  evaluating  and  annotating  the  data 
flow  junctors  (i.e.,  the  points  on  the  dfd  where  data  flows 
split  or  join),  and  evaluating  and  specifying  constraints 
describing  the  temporal  relationships  of  processes.  The 
entity  behavior  is  modeled  by  adding  information  pertaining 
to  initial  conditions,  final  conditions,  and  invariants. 
These  constraints  are  informally  specified  in  this  step  and 
refined  in  the  next  step. 

8.  Specify  constraints.  This  step  involves 
incrementally  refining  and  formally  specifying  the 
constraints  that  were  identified  in  the  previous  step.  It 
consists  of  three  subtasks:  model  internal  process 
constraints;  model  external  process  constraints;  and  model 
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entity    constraints.       A    predefined    core    of    reusable    objects/ 
constraints      is     defined      to     assist      in     the     formal 
specifications. 

9.  Write  formal  requirements  in  RMLf.  The  final  step 
formalizes  all  of  the  information  identified  in  the  previous 
steps.  The  relevant  information  has  been  identified  and 
each  graphic  component  has  a  formal  definition.  This  step 
involves  simply  writing  down  the  equivalent  RML'  definition 
for  the  constructs  specified.  Since  the  first  eight  steps 
of  the  methodology  have  already  produced  a  formal 
requirements  specification,  this  step  is  considered 
optional . 

These  nine  steps  are  examined  in  detail  in  the 
following    nine    sections. 


4.1  Identify  Objects  and  Processes 
Whether  one  is  using  an  object-oriented  approach  or  a 
functional  approach,  the  first  step  is  to  list  the  major 
objects  and/or  processes  in  the  system  being  modeled. 
Objects  and  processes  are  considered  equally  important. 
Brainstorming  is  suggested  to  assist  identification.  It  is 
best  to  alternate  between  objects  and  processes  to  avoid  one 
dominating  view.  Thus,  list  objects,  then  consider  what 
processes  operate  on  those  objects.  Then  consider  what 
processes  are  in  the  system,  and  what  objects  are  needed  by 
those    processes. 

Objects     and     processes     should     be     clustered     into 
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hierarchies.        Consider     aggregation     hierarchies     (the 
functional     approach)     for     both     processes     and     objects. 
Identify    specializations    of    objects    and    processes. 

This  step  is  illustrated  in  Figure  3.  The  major 
entities  and  processes  in  the  system  are  listed. 
Specializations  of  both  entities  and  processes  that  are 
known  at  this  initial  stage  are  listed.  In  our  example, 
'PERSON'  has  the  specializations  (subclasses)  'PATIENT'  and 
'CHILD.'  These  objects  are  further  decomposed  into  their 
subclasses  (e.g.,  'PATIENT'  has  the  specialization 
'  SURGICAL_PATIENT' ) ,  and  these  subclasses  are  similarly 
further  decomposed  as  necessary  (e.g.,  ' SURGICAL_PATIENT ' 
has     the     specialization     '  TRANSPLANT_SURGER Y_P ATIENT  '  )  . 

Aggregation  is  used  to  model  the  object/component 
relationships  for  both  entities  and  processes.  The  entity 
components  that  are  known  at  this  stage  are  actually  entity 
attributes  and  are  written  in  lower  case  letters  to 
illustrate  this  (e.g.,  'PERSON'  has  'name'  and  'age' 
attributes).  At  this  point  there  is  no  distinction  made 
between    permanent    or    temporary    attributes. 

The  process  components  that  are  listed  correspond  to 
those  resulting  from  the  typical  functional  decomposition. 
For  example,  the  'EVALUATE'  process  consists  of  the  subtasks 
'EXAMINE,'     'TEST,'    and    'ASSESS.' 
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MAJOR  OBJECTS  IN  SYSTEM 


ENTITIES 

PERSON 
PATIENT 
PHYSICIAN 
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TREAT 
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Figure  3:   Objects  and  Processes 
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4.2   Model  System  Dynamics 

A  simplified  dfd  is  used  that  consists  of  the  basic 
components:  processes,  data  flows,  and  external  sources. 
Data  stores  (files)  may  be  optionally  used.  Their  contents 
are  modeled  explicitly  during  the  structural  decomposition 
of  entities  to  alleviate  the  negative  criticisms  associated 
with  data  stores.  The  notion  of  control  information  found 
in  Ward  and  Mellor's  [War86]  version  and  SADT  [Ros77a, 
Ros77b]  may  either  be  included  at  this  point  or  added  later 
as  a  refinement.  Analyst's  accustomed  to  using  that 
notation  will  find  it  difficult  to  decompose  without  it, 
just  as  strict  SA  [Dem79]  or  SSA  [Gan79]  advocates  will 
consider  it  inappropriate  for  an  initial  dfd  decomposition. 
The  point  here  is  that  analysts  may  use  the  version  they 
feel  comfortable  with.  The  similarities  outweigh  the 
differences.  Whatever  information  is  not  included  during 
this  initial  decomposition  will  be  added  during  a  later  step 
of  the  methodology. 

Decomposition  of  both  processes  and  data  based  on  their 
aggregation  structures  occurs  at  this  level.  'Is-part-of 
hierarchies  for  processes  are  identified  as  in  any 
functional  decomposition.  The  data  is  also  decomposed 
("leveled"  in  SA  terminology)  as  in  all  dfd-based 
techniques . 

Figure  4  contains  two  dfds.  The  top  dfd  is  modeling 
'BE  A  HOSPITAL  PATIENT'  which  consists  of  four  subprocesses : 
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Figure  4:   System  Dynamics 
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'ADMIT, '  'EVALUATE,'  'TREAT,'  AND  'RELEASE.'  The  input  to 
this  system  is  a  'person'  and  the  output  from  this  system  is 
also  a  'person.'  The  'person'  becomes  a  'patient'  by  the 
'ADMIT'  process,  an  * evaluated_patient '  by  the  'EVALUATE' 
process,  and  a  '  treated_patient '  by  the  'TREAT*  process. 
The  controls  for  this  system  are  'ward,'  'physician,'  and 
'  consul ting_physician. ' 

The  lower  dfd  decomposes  'EVALUATE*  into  its 
components:  'EXAMINE,'  'TEST,*  and  'ASSESS.'  This  dfd 
illustrates  the  subpr ocessing  that  occurs  to  a  patient 
during  the  'EVALUATE'  process. 

All  processes  that  are  decomposed  into  components 
require  a  dfd  illustrating  their  decomposition.  These  dfds 
are  typically  organized  in  a  top-down  fashion.  The  entire 
collection  of  dfds  comprise  the  system  dynamics  modeled  in 
this  step. 

This  layer  of  the  model  should  identify  the  following: 

a.  processes/subprocesses ; 

b.  input/output  data  objects; 

c.  data  flows  (including  splits  &  joins);  and 

d.  external  entities. 

4.3   Model  Structure  of  Entities 

A  modified  entity-relationship  diagram  (erd)  is  used  to 

model  the  structure  of  the  entities.   Generalization  is  used 

to  model  class/subclass  entity  relationships  in  an  Entity 

Generalization  Structure  diagram.   Aggregation  is  used  to 
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model  object/component  entity  relationships  in  an  Entity 
Aggregation  Structure  diagram. 

There  are  two  possible  interpretations  of  entity 
decompositions  based  on  aggregation,  and  only  one  of  those 
is  modeled  in  this  step.  In  one  type,  the  component  objects 
are  viewed  as  permanent  attributes:  objects  whose  values  do 
not  change  over  the  lifetime  of  the  related  object  (e.g., 
the  'name'  attribute  of  object  'PERSON').  This  type  is 
treated  as  an  ob j ect/necpar t  decomposition  and  is  not 
modeled  in  this  step.  It  is  added  to  the  model  during 
refinement  when  related  objects  and  processes  are  specified. 

The  other  interpretation  of  entity  decomposition  based 
on  aggregation  corresponds  more  closely  to  the  conceptual 
modeling  interpretation  of  aggregation  and  parallels  the 
aggregation  decomposition  for  process.  Given  the  temporal 
framework  of  conceptual  modeling,  a  component  is  said  to 
exist  during  the  life-time  of  the  instance  of  the  aggregate 
object.  For  processes,  one  can  say  that  all  component 
subprocesses  occur  while  the  aggregate  component  is 
activated.  For  entities,  components  may  be  thought  of  as 
different  stages  the  aggregate  entity  may  be  in  during  its 
life-time . 

This  second  interpretation  of  entity  decomposition  also 
maps  onto  the  object/component  type  of  data  leveling  that 
occurs  in  dfds.  This  includes  entity  decompositions  that 
reflect  changes  in  the  life-cycle  of  the  entity  due  to  the 
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processes  it  has  undergone.  For  example,  a  'patient'  may  be 
an  "input"  to  an  EVALUATE  process  and  a  TREAT  process.  To 
reflect  the  various  processing  stages  of  the  'patient,'  the 
dfd  may  show  'patient'  being  an  "output"  from  the  processes 
as  '  evaluated_patient '  and  ' treated_patient . '  Viewing  these 
stages  as  components  of  the  aggregate  'patient'  would  imply 
that  an  instance  of  'patient'  has  attributes  'evaluated'  and 
' treated .  ' 

The  treatment  of  life-cycle  stages  of  entities  requires 
further  decomposition  and  the  specification  of  additional 
constraints.   They  are  examined  in  more  detail  in  step  7. 

The  entities  to  include  in  these  models  come  from  the 
initial  list  of  objects  and  the  dfd.  Only  those  entities 
identified  that  participate  in  class/subclass  or  object/ 
component  relationships  are  included  in  the  erds.  Some 
entities  identified  as  components  in  the  initial  list  of 
objects  may  be  determined  to  be  associated  objects  instead 
(e.g.,  'age'  because  the  value  is  not  fixed  over  the 
lifetime  of  the  PERSON  entity). 

Since  the  graphical  components  of  our  methodology  are 
formally  defined  in  the  conceptual  modeling  language  RML', 
their  semantics  must  be  equivalent  to  the  semantics  of 
RML'.  Therefore,  the  semantics  of  the  underlying  formalism 
must  be  reviewed  at  this  point. 

Recall  that  objects  are  organized  hierarchically  based 
on  the  three  abstraction  mechanisms:    classification, 
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generalization,  and  aggregation.  This  means  that  objects 
are  organized  based  on  'is-a,'  '  is-part-of , '  and  'instance- 
of'  hierarchies.  Our  graphical  representation,  like  the 
underlying  RML '  ,  has  separate  'is-a'  and  'is-part-of' 
hierarchies  but  has  combined  ' instance-of '  hierarchies  with 
the  other  two  as  necessary.  This  results  in  generalization 
('is-a')  diagrams  and  aggregation  ('is-part-of')  diagrams 
for  both  entities  and  processes. 

Each  object  has  an  object  definition  that  includes  the 
object  name  followed  by  one  of  the  abstraction  operators 
('isa,'  'part-of,'  or  'in')  and  one  or  more  other  objects. 
Specifically,  an  object  may  be  in  (i.e.,  be  an  instance  of) 
one  or  more  other  objects  (e.g.,  'A  in  B'  and  'A  in  B,  C 
are  both  syntactically  correct);  an  object  may  be  isa  one  or 
more  other  objects  (e.g.,  'A  isa  B'  and  'A  isa  B,  C  are 
both  syntactically  correct);  and  an  object  may  be  part-of 
one  other  object  (e.g.,  'A  part-of  B'  is  correct).  (See 
Appendix  A  for  the  complete  syntax.)  The  semantics  of  the 
abstraction  operators  are  implied  in  the  diagrams. 

In  generalization  diagrams,  objects  are  organized 
hierarchically  based  on  the  isa  abstraction  operator.  The 
diagrams  should  be  read  from  bottom  to  top  with  the 
specializations  below  their  generalizations.  In  aggregation 
diagrams,  objects  are  organized  hierarchically  based  on  the 
part-of  abstraction  operator.   These  diagrams  should  be 
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read  from  bottom  to  top  with  the  components  below  their 
aggregates. 

In  addition  to  the  overall  hierarchical  organization  of 
objects  based  on  the  abstraction  mechanisms,  recall  that 
objects  are  related  to  other  objects  through  properties,  and 
different  object  types  have  different  property  categories. 
Since  these  relationships  are  specified  within  the  object 
definition  in  the  underlying  formal  representation,  they 
must  be  graphically  specified  in  a  similar  manner. 
Therefore,  an  object's  properties  are  defined  with  the 
object  on  the  appropriate  diagrams. 

The  Entity  Generalization  Structure  diagram  models  the 
system  from  an  'is— a'  point  of  view.  However,  the 
components  of  any  items  participating  in  obj  ect /component 
relationships  are  also  included  in  the  model.  This  sets  up 
a  link  between  the  two  diagrams  created  in  this  step.  An 
asterisk  is  used  to  denote  that  the  object  is  decomposed 
further  in  another  diagram. 

The  Entity  Generalization  Structure  diagram  for  our 
example  is  given  in  Figure  5.  'PERSON'  is  the 
generalization  of  both  'PATIENT'  and  'CHILD'  (i.e.,  'PATIENT 
is-a  PERSON'  and  'CHILD  is-a  PERSON').  ' CHILD_PATIENT*  has 
both  'PATIENT'  and  'CHILD'  as  generalizations  (i.e.,  'CHILD_ 
PATIENT  is-a  PATIENT,  CHILD').  The  only  properties  shown  on 
this  diagram  are  component  properties  because  they  represent 
an  aggregation  decomposition.  The  component  properties  of 
'PATIENT'  are  'EVALUATED  PATIENT*  and  'TREATED  PATIENT.' 


61 


Key: 


*  — 


fc>_ 


decomposed  on 
another  diagram 
component 


fEVALUATeD-^ 
V.   PATIENT     J 


V   >rfrie»n-    7 


*VR.(rl£Al.- 

pa-tiGwT 


TRAVSPLANTL 
SuR6^*V 

patent 


PERSON 


CttlLD- 
PATIENT 


Sl/R>tCAL- 
PATiENT 


Figure    5:       Entity    Generalization    Structure 


62 
Note  that  '  EVALUATED_PATIENT '  is  decomposed  further  in 
another  diagram. 

The  Entity  Aggregation  Structure  diagram  models  the 
system  from  an  'is-part-of'  point  of  view.  The  entities  to 
include  in  this  model  participated  in  an  object/component 
relationship  on  the  previous  diagram,  although  some  of  the 
entities  may  be  the  result  of  further  decomposition. 

Figure  6  illustrates  the  Entity  Aggregation  Structure 
diagram  for  our  example.  Both  * EVALUATED_PATIENT '  and 
' TREATEDJPATIENT'  are  'part-of  related  to  the  aggregate 
•PATIENT.'  ' EXAMINED_PATIENT'  and  ' TESTED_PATIENT'  are  the 
result  of  further  decomposition  and  are  hidden  with  an 
asterisk  on  the  Entity  Generalization  Structure  diagram. 

This  layer  of  the  model  should  identify  the  following: 

a.  the  generalization  structure  of  entities;  and 

b.  the  aggregation  structure  of  entities. 

4.4  Model  Structure  of  Processes 
A  modified  erd  is  used  to  model  the  structure  of  the 
processes.  Generalization  is  used  to  model  class/subclass 
process  relationships  in  a  Process  Generalization  Structure 
diagram.  Aggregation  is  used  to  model  object/component 
process/subprocess  relationships  in  a  Process  Aggregation 
Structure  diagram. 

The  process/subprocess  relationships  were  previously 
modeled  in  the  dfd  layer.  They  are  repeated  here  for 
consistency.   This  often  entails  more  information  than  can 
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be  expressed  in  a  single  diagram.  Decompose  in  layers  as 
necessary.  The  final  results  should  include  both 
aggregation  and  generalization  decompositions  for  individual 
processes.  Lower  level  components  may  be  hidden  by  using  an 
asterisk . 

The  Process  Generalization  Structure  diagram  models  the 
system  from  an  'is~a'  point  of  view.  As  in  the  previous 
Entity  Generalization  Structure  diagram,  the  components  of 
any  objects  participating  in  object/component  relationships 
are    also    included    in    the    model. 

Figure  7  is  the  Process  Generalization  Structure 
diagram  for  our  example.  It  models  the  subclasses  of  the 
'ADMIT'  process.  '  ADMIT_SURGICAL_CHILD_PATIENT'  has  both 
1  ADMIT_CHILD_PATIENT'  and  '  ADMIT_S  URGIC  AL_P  ATIENT  '  as 
generalizations.  This  diagram  shows  the  component 
properties  of  'ADMIT'  ('CHECK_ID,'  '  CHOOSE_WARD  ,  '  and 
'PERFORM_TESTS' )  and  the  additional  component  properties  of 
the  specializations  of  'ADMIT'  (e.g.,  ' ADMIT_CHILD_P ATIENT' 
has    the    additional    component    ' FIND_NURSE' ) . 

The  Process  Aggregation  Structure  diagram  models  the 
system  from  an  'is-part-of'  point  of  view.  Aggregate 
processes  are  decomposed  into  their  components.  In  Figure 
8,  'ADMIT'  is  decomposed  into  its  components  'CHECK_ID,' 
'CHOOSE_WARD,  '  and  '  PERFORM_TESTS .  '  Note  that  'ADMIT'  is 
'part-of  'BE_A_HOSPITAL_PATIENT'  as  illustrated  on  the 
System   Dynamics    diagram    (Figure    A). 
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This    layer    of    the    model    should    identify    the    following: 

a.  the    generalization    structure    of    processes;    and 

b.  the   aggregation    structure    of    processes. 


4.5      Refine    Entities 

This  step  introduces  concepts  associated  with  the 
conceptual  modeling  language.  It  represents  a  shift  in 
perspective  from  what  is  typically  considered  analysis  to  a 
more  detailed  analysis  necessary  for  formalization.  It 
consists  of  two  subtasks:  identify  related  objects  and 
processes;  and  specify  c 1  a ss /me t ac las s  refinement. 
Information  is  incrementally  added  to  the  entity  structure 
diagrams    obtained    in    step    3. 

The  first  subtask  identifies  related  objects  and 
processes.  Related  objects  are  either  associated  objects  or 
necessary  part  objects.  Objects  associated  with  the 
entities  whose  values  may  change  over  the  lifetime  of  the 
related  entity  are  considered  temporary  attributes. 
Necessary  parts  have  values  that  do  not  change  over  the 
lifetime  of  the  entity  and  are  considered  fixed  attributes. 
Related  processes  are  those  typically  identified  in 
conceptual  modeling  approaches:  processes  that  create  the 
entity,  modify  the  entity,  or  consume  the  entity.  These 
processes  are  identified  and  their  relationships  are 
specified. 

The  second  subtask  utilizes  the  classification 
abstraction     mechanism     to     specify      'in'      related     class/ 
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metaclass  instances.  All  entities  specified  previously  are 
treated  as  class  names.  Metaclass  names  are  added  and  may 
be  either  user-defined  or  built-in.  Metaclasses  are  built- 
in  unless  there  are  associated  metaclass  attributes.  For 
user-defined  metaclasses,  associated  attributes  must  be 
identified . 

All  previously  defined  attributes  and  relationships 
represent  properties  of  the  associated  entity.  Class  names 
of  the  property  values  must  be  specified  for  each  of  these 
properties.  These  class  names  identify  the  class  that  the 
value  of  the  related  object  must  come  from.  All  previously 
specified  components  are  treated  as  class  names  and  their 
attributes  must  be  specified. 

Using  multiple  inheritance,  provide  specialized 
property  values  for  subclasses  as  appropriate.  Also 
identify  any  relevant  additional  attributes  associated  with 
subclasses . 

The  Entity  Generalization  Structure  diagram  (Figure  5) 
obtained  in  step  3  is  the  starting  point  for  the  Refined 
Entity  Generalization  Structure  diagram  (Figure  9)  created 
in  this  step.  Similarly,  information  is  incrementally  added 
to  the  Entity  Aggregation  Structure  diagram  (Figure  6)  to 
create  the  Refined  Entity  Aggregation  Structure  diagram 
(Figure  10). 

Consider  Figure  9,  the  Refined  Entity  Generalization 
Structure  diagram.   For  'PERSON,1  the  associated  objects  are 
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Figure    9:       Refined    Entity    Generalization    Structure 
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'address,'  'age,'  and  ' insurance_# .  '  Note  that  associated 
objects  are  shown  on  the  right  side  of  each  entity  box  for 
consistency.  'PERSON'  has  as  necessary  part  objects  'name,' 
and  ' social_security# . '  These  objects  are  fixed  attributes 
with  values  that  do  not  change  over  the  life-time  of 
'PERSON.'  Note  that  necessary  part  objects  are  shown  on  the 
left  side  of  the  entity  box.  Since  the  semantics  of  related 
processes  correspond  to  the  information  contained  in  the 
Refined  Entity  Aggregation  Structure  diagram,  they  are 
modeled  in  that  diagram  and  are  discussed  below  with  that 
example . 

The  entities  previously  specified  represent  class  names 
(e.g.,  'PERSON'  and  'PATIENT').  'PERSON'  is  an  instance  of 
the  user-defined  metaclass  ' PERS0N_CLASS , '  which  is  an 
instance  of  the  built-in  metaclass  ' ENTITY_METACLASS .  '  The 
associated  metaclass  attributes  'aver_age'  and  'cardinality' 
are  identified  for  the  user-defined  metaclass  ' PERS0N_ 
CLASS. ' 

'PERSON'  has  'name,'  ' social_secur it y , '  'address,' 
'age,'  and  ' i nsu r a nc e_# '  properties.  Each  of  these 
properties  has  an  associated  property  value  (e.g.,  the 
'name'  property  of  'PERSON'  has  the  property  value  'PERS0N_ 
NAME'). 

The  previously  specified  components  ' TREATED_PATIENT ' 
and  ' EVALUATED_PATIENT'  represent  class  names.  Their 
attributes  are  'treat'  and  'evaluate'  respectively. 
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Property  values  for  inherited  properties  of  subclasses 
are  specialized  (e.g.,  the  property  value  of  the  'age' 
property  for  'CHILD'  is  '  CHI LD_AGE_VALUE '  which  is  a 
specialization  of  ' AGE_VALUE' ) .  ' SURGICAL_PATIENT'  has  the 
additional  properties  'blood_type'  and  'surgery'  and  their 
respective  property  values  are  ' BLOOD_TYPE '  and  '  SURGERY_ 
TYPE.' 

Figure  10  is  the  Refined  Entity  Aggregation  Structure 
diagram.  Any  associated  objects  or  necessary  part  objects 
identified  on  the  previous  diagram  are  repeated  here  (e.g., 
'PATIENT'  has  the  associated  objects  'ward,'  'physician,' 
and  '  consul t ing_phy sician ' )  and  their  property  values  are 
given  (e.g.,  'ward*  has  the  property  value  ' H0SPITAL_WARD' ) . 

Related  processes  are  identified  for  each  entity 
(e.g.,  'ADMIT'  creates  'PATIENT,'  'EVALUATE'  and  'TREAT' 
modify  'PATIENT,'  and  'RELEASE'  consumes  'PATIENT')  and 
their  relationships  are  specified  (e.g.,  the  'ADMIT'  process 
is  related  to  'PATIENT'  by  the  'register'  property). 
Related  processes  for  component  entities  are  identified  and 
their  relationships  are  specified  (e.g.,  'TREATED_PATIENT' 
is  created  by  'TREAT'  and  the  relationship  is  described  by 
the  'treat'  property). 

Note  that  there  are  no  'in'  related  objects  modeled  on 
the  diagram.  Since  the  Refined  Entity  Generalization 
Structure  diagram  illustrates  that  'PATIENT  is-a  PERSON'  and 
'PERSON  in  PERS0N_  CLASS,'  we  know  that  'PATIENT  in 
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PERSON_CLASS'  by  the  semantics  of  'is-a'  and  'in'  described 
in  Appendix  B.   This  inheritance  is  implied  in  the  Entity 
Generalization  diagram  and  is  not  repeated  here. 

Finally,  the  additional  properties  associated  with 
component  entities  are  identified  and  their  property  values 
specified  (e.g.,  ' EVALUATED_PATIENT '  has  the  associated 
property  'physician'  with  the  property  value  'PHYSICIAN'). 

This  layer  of  the  model  should  identify  the  following: 

a.  associated  objects  (temporary  attributes); 

b.  necessary  part  objects  (fixed  attributes); 

c.  related  processes  (created  by,  modified  by, 
and  consumed  by)  and  relationships; 

d.  the  classification  structure  of  entities; 

e.  class  names  of  property  values; 

f.  specialized  property  values  or  additional 
attritutes  for  subclasses  based  on  multiple 
inheritance;  and 

g.  metaclass   attributes. 

4.6  Refine  Processes 
This  step  applies  concepts  associated  with  the 
conceptual  modeling  language  to  processes.  It  consists  of 
two  subtasks:  identify  input,  output,  and  associated 
objects;  and  specify  c 1  a s s / m e t a c 1  a s s  refinement. 
Information  is  incrementally  added  to  the  process  structure 
diagrams    obtained    in    step    4. 
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The  first  subtask  identifies  input  and  output  objects 
and  other  associated  objects.  The  input  and  output  objects 
have  already  been  identified  on  the  dfd  and  are  just  copied 
onto  the  process  erds.  The  semantics  of  input  and  output  in 
the  conceptual  modeling  language  should  be  considered. 
Input  entities  participate  in  the  process  and  are  removed 
from  their  property  value  class  by  this  process  (i.e., 
input  is  consumed).  Output  entities  are  inserted  into  their 
given  property  value  class  by  this  activity  (i.e.,  output 
is  produced). 

The  associated  objects  are  objects  affecting  the 
process  but  not  consumed  by  the  process.  These  entities 
correspond  to  control  items  that  may  have  been  identified  on 
the  dfd.  If  control  information  was  not  included  on  the  dfd 
then  it  needs  to  be  added  here.  Consider  entities  that 
constrain  the  process  in  some  way  and  are  needed  by  the 
process.  Control  entities  serve  as  input  to  the  process  but 
they  differ  from  input  entities  in  that  they  still  exist 
after  the  process  terminates. 

The  second  subtask  utilizes  the  classification 
abstraction  mechanism  to  specify  'in'  related  class/ 
metaclass  instances.  All  processes  specified  previously 
are  treated  as  class  names.  Metaclass  names  are  added  and 
may  be  either  user-defined  or  built-in.  Metaclasses  are 
built-in  unless  there  are  associated  metaclass  attributes. 
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For    user-defined    metaclasses,     associated    attributes    must    be 
identified. 

All  previously  identified  related  entities  represent 
properties  of  the  associated  process.  Class  names  of  the 
property  values  must  be  specified  for  each  of  these 
properties.  These  class  names  identify  the  class  that  the 
value  of  the  related  object  must  come  from.  All  previously 
specified  components  are  treated  as  class  names  and  their 
attributes   must    be    specified. 

Using  multiple  inheritance,  provide  specialized 
property  values  for  subclasses  as  appropriate.  Also 
identify  any  additional  properties  associated  with 
subclasses   and    specify    their    property    values. 

Figure  11  is  the  Refined  Process  Generalization 
Structure  diagram  for  our  example.  The  input  to  'ADMIT'  is 
'person'  and  its  property  value  class  is  'PERSON.'  'ADMIT' 
produces  the  output  'patient'  which  is  inserted  into  the 
property  value  class  'PATIENT'  by  this  process.  'ADMIT'  has 
associated  properties  'ward,'  'physician,'  and  'consulting_ 
physician.'  These  objects  are  not  removed  from  their 
property  value  classes  by  this  process  (e.g.,  'physician'  is 
not    removed    from    'PHYSICIAN'     by    this    process). 

Note  that  'ADMIT'  has  no  'in'  related  class/metaclasses 
specified.  This  is  because  'ADMIT'  is  'part-of  the 
aggregate    process    ' BE_A_HOSPITAL_PATIENT'    which    is 
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Figure  11:   Refined  Process  Generalization  Structure 
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illustrated  on  the  Refined  Process  Aggregation  Structure 
diagram. 

The  previously  identified  components  represent  class 
names  (e.g.,  'CHECK_ID')  and  their  attributes  are  specified 
(e.g.,  the  attribute  of  'CHECK_ID'  is  'check_id'). 

Specialized  property  values  for  subclasses  are  given 
(e.g.,  the  property  value  of  the  'patient'  property  of 
'ADMIT_CHILD_PATIENT'  is  ' CHILD_PATIENT '  which  is  a 
specialization  of  'PATIENT').  Additional  properties 
associated  with  subclasses  are  provided  and  their  property 
values  are  identified  (e.g.,  '  ADMIT_SURGICAL_PATIENT'  has 
the  associated  properties  'blood_type'  and  'surgery'  with 
property  values  ' BLOOD_TYPING'  and  ' SURGERYJTYPE' ) . 

The  Refined  Process  Aggregation  Structure  diagram  for 
our  example  is  given  in  Figure  12.  'ADMIT'  has  components 
'CHECK_ID,'  'CHOOSE_WARD, '  and  '  PERFORM_TESTS . '  'ADMIT'  is 
'part-of  the  aggregate  '  BE_A_HOSPITAL_PATIENT'  and  that 
hierarchical  relationship  is  also  included  in  this  model. 

The  input  to  'ADMIT'  is  'person'  and  its  property  value 
class  is  'PERSON.'  The  output  from  'ADMIT*  is  'patient'  and 
its  property  value  class  is  'PATIENT.'  The  associated 
properties  of  'ADMIT'  and  their  property  value  classes  are 
copied  from  the  previous  diagram  because  they  may  be 
associated  with  the  component  processes.  In  our  example, 
' CH00SE_WARD '  has  the  associated  property  'ward'  and 
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'PERFORM_TESTS'  has  the  associated  properties  'physician' 
and  ' consulting_physician. ' 

The  input  and  output  objects  for  the  components  are 
specified  with  their  property  values  (e.g.,  the  input 
property  of  'CHECK_ID'  is  'person'  with  the  property  value 
class  'PERSON'  and  the  output  property  is  'identified'  with 
the  property  value  ' IDENTIFIEDJPATIENT' ) . 

This  layer  of  the  model  should  identify  the  following: 

a.  input  and  output  objects; 

b.  associated  objects  (objects  affecting  the 
process  but  not  consumed  by  the  process); 

c.  the  classification  structure  of  processes; 

d.  class  names  of  property  values; 

e.  specialized  property  values  or  additional 
attritutes  for  subclasses  based  on  multiple 
inheritance;  and 

f.  metaclass  attributes. 

4.7  Annotate  to  Refine  Dynamics 
This  step  bridges  the  gap  between  analysis  and 
specification.  Analysis  techniques  are  used  to  build  models 
that  are  intentionally  vague.  This  vagueness  allows  the 
analyst  to  concentrate  on  the  structure  of  the  overall 
system  and  consequently,  avoid  dealing  with  the  details. 
However,  at  some  point  those  details  must  be  considered. 
This  is  that  point.  Keep  in  mind  that  the  information 
identified  in  this  layer  is  still  not  procedural.   There  are 
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no  control  structures  specified.  The  information  supplied 
at  this  level  is  needed  to  precisely  interpret  the  meaning 
of  the  dynamic  model  obtained  in  step  2.  (See  Figure  4.) 
This  step  consists  of  three  subtasks:  model  internal 
process  behavior;  model  external  process  behavior;  and  model 
entity  behavior. 


4.7.1   Model  Internal  Process  Behavior 

The  first  subtask  involves  modeling  the  internal 
behavior  of  the  processes.  The  view  is  taken  that  the 
function  of  a  process  can  be  described  without  discussing 
the  algorithm  or  procedure  that  will  be  used.  This 
coincides  with  the  notion  of  information  hiding  which  is 
central  to  the  methodology.  The  assumption  is  that  we  can 
describe  and  understand  a  process  in  terms  of  its 
constraints  without  considering  procedural  details.  Pre-/ 
postconditions  are  a  familiar  way  to  express  this 
information. 

Preconditions  describe  all  the  things  that  must  be  true 
before  the  process  begins  operating.  Yourdon  [You89] 
discusses  the  types  of  information  typically  described  by 
preconditions.   These  include: 

1.  What  inputs  must  be  available.  Even  though  a 
process  may  have  more  than  one  input  flow  into  a 
process,  they  may  not  all  be  required  to  activate 
the  process.  Some  of  the  inputs  may  be  needed 
during  the  process  but  are  not  necessary  for  the 
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process  to  begin  doing  its  work.   Preconditions 
specify  which  input  items  are  necessary  for  the 
process  to  begin. 

2.  What  relationships  must  exist  between  inputs 
or  within  inputs.  A  precondition  might  specify 
that  two  inputs  with  matching  fields  must  arrive 
or  that  one  component  of  a  data  item  must  be 
within  a  certain  range. 

3.  What  relationships  must  exist  between  inputs 
and  data  stores.  A  precondition  might  specify 
that  there  be  a  record  within  a  data  store  (or  a 
token  in  an  associated  class)  that  matches  some 
aspect  of  an  input  data  item. 

4.  What  relationships  must  exist  between 
different  stores  or  within  a  single  store.  A 
precondition  might  stipulate  that  a  record  (token) 
exists  with  an  attribute  that  matches  an  attribute 
of  another  record  (token)  in  a  different  store 
(class) . 

Postconditions  describe  what  must  be  true  when  the 
process  has  finished  doing  its  job.  Yourdon  [You89]  also 
discusses  the  types  of  information  described  by 
postconditions.   These  include: 

1.   The  outputs  that  will  be  generated  or  produced 

by  the  process. 
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2.  The  relationships  that  will  exist  between 
output  values  and  the  original  input  values.  This 
is  typically  used  when  an  output  is  a  direct 
mathematical  function  of  an  input  value. 

3.  The  relationships  that  will  exist  between 
output  values  and  values  in  one  or  more  stores. 
This  is  used  when  information  is  retrieved  from  a 
store  (class)  and  used  as  part  of  an  output  of  the 
process. 

4.  The  changes  that  will  have  been  made  to 
stores.  This  is  used  when  new  items  have  been 
added,  existing  items  have  been  modified,  or 
existing  items  have  been  deleted  from  stores 
(classes) . 

Due  to  the  inherent  vagueness  of  dfds,  a  process 
specified  in  a  dfd  can  represent  more  than  one  activation, 
each  having  different  participating  inputs,  controls,  and 
outputs.  One  task  addressed  in  this  step  is  to  identify 
the  possible  combinations  of  inputs,  outputs,  and  controls. 
Each  combination  is  an  activation  and  can  be  specified  by  an 
activation  rule.  The  combination  of  inputs,  outputs,  and 
controls  form  the  interface  of  the  process.  The  following 
interface  operators  will  be  used  to  describe  the 
combinations:  +  (or),  *  (and),  and  x  (xor).  Activation 
rules  show  which  inputs  and  controls,  together  with  the 
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appropriate  interface  operators,  produce  what  combination  of 
outputs,  using  interface  operators  as  needed. 

Figure  13  shows  a  process  with  input,  output,  and 
control . 


Figure  13:   Process  Interface 


Interface  operators  have  been  added  to  the  diagram  to 
illustrate  the  combinations.   The  resulting  activation  is: 

II  *  12  *  CI  -->  01  x  02 
This  rule  states  that  both  input  objects  and  the  control 
object  are  needed  to  activate  the  process.   The  described 
activation  will  produce  either  01  or  02  but  not  both. 

Several  questions  arise  based  on  the  above 
specification.  Marca  and  McGowan  [Mar88]  consider  the  left 
side  of  the  rule  to  be  the  precondition  and  the  right  side 
to  be  the  postcondition.  Do  these  adequately  represent  the 
pr  e-/postcondi  tions?  What  are  the  triggering  conditions 
and  how  do  they  differ  from  the  preconditions?  What  does 
the  activation  rule  really  tell  us  about  the  internal 
behavior  of  this  process? 
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The     above     questions     have     been     considered     and     the 
following    conclusions    have    been   made: 

1.  The  left  side  of  the  activation  rule  indicates 
what  information  is  needed  for  the  process  to 
become  activated  (i.e.,  Yourdon's  first  type  of 
precondition)  and  is  considered  a  triggering 
condition. 

2.  The  right  side  of  the  activation  rule 
indicates  what  outputs  are  produced  and  is 
considered  a  postcondition  (i.e.,  Yourdon's  first 
type    of    postcondition). 

3.  If  any  operators  other  than  AND  are  used  in  an 
activation  rule  or  if  the  process  has  more  than 
one  activation  rule,  then  the  process  is  not 
elementary  and  the  internal  behavior  of  the 
process  is  not  understood.  Each  non-elementary 
process  must  be  decomposed  into  subprocesses  that 
are    elementary. 

4.  Preconditions  and  postconditions  typically 
specify  semantic  information  (e.g.,  relationships 
between  inputs,  outputs,  and  existing  classes; 
acceptable  ranges  of  data  values;  and  changes  to 
associated  data  (classes  or  stores))  and  thus 
contain  more  application  dependent  information 
than     that     which     is     specified     in    an    activation 
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rule.        Elementary     process    decompositions     can     be 

used    to    identify    semantic    pre-/postconditions. 

To  illustrate  the  above  conclusions  it  is  necessary  to 
examine  what  a  process  at  the  conceptual  modeling  level 
does.  In  essence,  when  a  process  is  activated,  it  takes 
instances  of  the  input  class(es)  and  places  them  in  the 
output  class(es).  Associated  objects  may  be  altered, 
component  processes  may  be  activated  (if  they  exist),  and 
constraints  may  be  asserted.  If  the  triggering  conditions 
are  met  and  the  preconditions  are  satisfied,  the 
postconditions  will  be  true  and  the  output  will  be 
produced.  In  other  words,  the  process  works.  But  if  the 
process  specification  is  ambiguous,  then  this  process 
behavior  must  be  examined  more  closely  to  determine  what 
should    happen   when    the    process    works. 

Consider  the  following  example.  Assume  the  ADMIT 
process    was    specified    as    in    Figure    14. 


person 


■> 


ADMIT  x 


patient 
> 

r  e  j  e  c  t  e  d_p  a  t  i  e  n  t 
> 


Figure    14:       Non-elementary    Process 


The    activation    rule    is: 

person    — >    patient    x    rej ected_patient . 
This    means    that    ADMIT    is    activated    when    a    person    arrives    and 
produces     either     a     patient     or     a     rej ected_patient    but    not 
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both.   Thus  the  postcondition  based  on  the  above  activation 
rule  would  not  be  able  to  assert  what  output  was  produced  by 
the  process  (i.e.,  which  property  value  class  the  entity  was 
inserted  into). 

The  above  ambiguity  is  due  to  the  fact  that  the  process 
is  non-elementary.  In  order  to  clarify  the  intended 
behavior  of  the  process,  one  must  decompose  the  process 
until  all  components  are  elementary.   See  Figure  15. 


PERSON 


"> 


PATIENT 


V 


ADMIT 


V 


-> 


REJECT_ 
ADMISSION 


* 


PATIENT 


REJECTED 
PATIENT 


■> 


Figure  15:   Elementary  Process  Decomposition 


The  activation  rule  for  ADMIT  is: 

PERSON  — >  PATIENT 
and  the  activation  rule  for  REJECT_ADMISSION  is 

PERSON  — >  REJECTED_PATIENT. 
These  tell  us  that  the  triggering  condition  is  the  arrival 
of  an  instance  of  PERSON  in  both  cases.   Note  that  the 
control  object  (PATIENT)  is  not  needed  for  either  process  to 
become  activated.   Control  information  is  included  in  the 
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triggering  condition  (i.e.,  the  left  side  of  the  activation 
rule)  if  the  arrival  of  that  information  activates  the 
process.  In  some  cases  the  control  information  represents  a 
data  store  (i.e.,  an  existing  class)  and  the  precondition 
must  specify  how  that  data  store  (class)  is  being  used 
(e.g.,  some  attribute  of  a  record  (token)  must  match  some 
aspect  of  the  input  data  item).  The  postconditions  simply 
assert  what  output  is  produced.  Even  though  this  is  clearer 
than  in  the  previous  example  (i.e.,  we  know  that  ADMIT 
produces  a  PATIENT),  we  still  don't  know  under  what 
conditions  a  person  is  admitted  or  rejected.  This  type  of 
semantic  information  is  needed  to  clarify  the  function  of 
each  of  the  above  processes  and  is  specified  as 
preconditions. 

Writing  these  pr e-/postcondi tions  involves  digging 
into  the  innerworkings  of  the  system  being  modeled.  It  may 
entail  a  design  decision  if  this  information  is  not 
available.  In  this  example,  assume  that  the  only  reasons  a 
person  will  not  be  admitted  are  if  they  are  already  a 
patient  in  the  hospital  or  if  there  is  no  more  room  left  in 
the  hospital.  Similarly,  a  person  will  be  admitted  if  they 
are  not  already  a  patient  in  the  hospital  and  there  is  room 
left. 

This  step  identifies  the  triggering  conditions  (or 
actcond)  and  pre-/postconditions  by  stating  them  in  short 
phrases.    These  phrases  will  be  the  basis  for  further 
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refinement  in  the  next  step.  The  content  of  these  short 
phrases  typically  involves  stating  or  negating  related 
assertions,  specifying  the  arrival  of  an  object  in  the  case 
of  activation  conditions,  and  asserting  that  an  object  is  or 
is  not  in  another  object  in  pre-/postconditions. 
Continuing  the  above  example,  the  applicable 
constraints    are    informally    specified    as    in    Figure    16. 

ADMIT 

actcond:        person  arrives 

precondition:   person  not  already  a  patient 

room  left 
postcondition:  person  in  hospital 

REJECT_ADMISSION 

actcond:        person  arrives 
precondition:   person  already  a  patient 

no  more  room  left 
postcondition:  person  not  in  hospital 

Figure  16:   Preliminary  Act-/Pre-/Postconditions 

4.7.2   Model  External  Process  Behavior 

The  second  subtask  of  this  step  is  to  model  the 
external  process  behavior.  This  task  pertains  to  making 
explicit  certain  types  of  information  that  are  implicitly 
represented  on  dfds.  This  includes  specifying  constraints 
describing  the  life-cycle  stages  of  entities,  evaluating  and 
annotating  the  data  flow  junctors  (i.e.,  the  points  on  the 
dfd  where  data  flows  split  or  join),  and  evaluating  and 
specifying  constraints  describing  the  temporal  relationships 
of  processes.  A  set  of  predicates  is  defined  in  this 
section  to  be  used  in  the  temporal  constraints. 
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The  information  identified  in  this  step  will  be 
expressed  as  informal  constraints  which  are  formally  defined 
in  the  next  step. 

It  is  believed  that  making  this  information  explicit 
will  improve  the  quality  of  the  requirements.  However,  it 
is  also  realized  that  including  too  much  of  this  type  of 
information  will  be  detrimental  to  the  system  as  it 
decreases  design  flexibility.  Therefore,  determining  which 
types  of  constraints  are  necessary  and  which  types  should  be 
avoided  are  essential  tasks  that  must  be  addressed  during 
this  step.  Guidelines  for  evaluating  constraints  are 
presented  to  assist  the  analyst  in  this  task. 

The  first  set  of  constraints  that  needs  to  be  modeled 
concerns  the  representation  of  life-cycle  changes  of 
entities.  The  problem  of  entity  life-cycle  changes  is 
inherent  in  a  methodology  that  combines  an  object-oriented 
approach  with  an  analysis  technique  based  on  functional 
decomposition.  Dfds  show  the  processes  that  comprise  a 
system  and  the  data  that  flows  into  and  out  of  those 
processes.  This  typically  includes  data  items  that  are 
modified  somewhat  by  the  processes  they  undergo.  For 
example,  an  EVALUATE  process  may  take  a  'patient'  as  an 
"input"  and  produce  ' e valuated_patient '  as  an  "output." 
This  '  evaluated_patient '  may  then  serve  as  "input"  to  a 
TREAT  process  and  appear  as  the  "output"  '  treated_patient ' 
(see  Figure  4).  Each  of  these  different  data  flows  reflect  a 
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different  life-cycle  stage  of  the  data  item  'patient.'   That 
is,  the  primary  distinction  between  the  data  acting  as  an 
input  to  and  output  from  a  process  is  simply  that  it  has 
undergone  the  process. 

It  is  standard  practice  to  use  different  names  for  the 
data  flowing  into  and  out  of  a  process.   The  problem  occurs 
when  trying  to  tie  that  practice  into  an  object-oriented 
framework.   Recall  that  object-oriented  approaches  decompose 
a  system  based  on  the  'is-a'  structure  of  the  data.   Since 
these  different  stages  do  not  reflect  generalization 
decompositions  (i.e.,  they  are  not  different  types  of 
patients)  they  do  not  appear  on  'is-a'   hierarchies. 
Considering  them  distinct,  unrelated  objects  does  not  seem 
appropriate  either.   Furthermore,  they  play  a  unique  role 
in  that  all  of  the  subtypes  of  the  data  item  also  undergo 
the  same  processes  and  have  the  same  life-cycle  stages. 
Thus,  'CHILD_PATIENT, '  ' SURGICAL_PATIENT , '  'TRANSPLANT_ 
SURGERY_PATIENT, '  and  ' SURGICAL_CHILD_PATIENT '  all  undergo 
EVALUATE  and  TREAT  processes  since  they  are  all  'is-a' 
related  to  'PATIENT.'   Therefore,  all  instances  of  each  of 
these  classes  will  have  the  life-cycle  stages  'evaluated_ 
patient'  and  ' treated_patient .  ' 

Solutions  to  deal  with  the  above  problem  that  were 
considered  include  using  a  state  transition  diagram  to  model 
the  different  states  of  an  object,  viewing  the  different 
data  items  as  the  same  object  but  with  different  attributes, 
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and  considering  the  different  stages  as  a  new  type  of  object 
decomposition. 

It  was  determined  that  the  utilization  of  a  state 
transition  diagram  to  model  the  different  life-cycle  stages 
of  an  object  would  not  solve  the  problem.  More  importantly, 
it  would  add  unnecessary  complications. 

The  problem  is  due  to  the  junctors.  If  we  allow  the 
states  to  be  the  different  life-cycle  stages  of  an  object 
(i.e.,  the  data  flows),  then  the  processes  should  be  the 
transitions.  Furthermore,  the  only  changes  that  occur  to 
the  states  occur  as  a  result  of  a  transition  (a  process). 
Since  the  data  flows  on  a  dfd  represent  a  collection  of 
data,  dfd  convention  allows  these  flows  to  be  split  and/or 
joined  into  component  data  flows.  These  resultant  component 
or  aggregate  data  flows  also  correspond  to  a  different  life- 
cycle  stage  of  an  object  and  should  therefore  be  denoted  by 
a  new  state.  However,  these  new  states  occur  between 
transitions.  Therefore,  junctors  have  to  be  considered 
transitions.  But  this  contradicts  the  semantics  of  dfds 
which  state  that  nothing  "happens"  between  processes.  Due 
to  this  obvious  mismatch  of  representations,  the 
incorporation  of  state  transition  diagrams  to  model  entity 
life-cycle  stages  was  abandoned. 

The  solution  to  this  representation  problem  developed 
as  a  result  of  combining  the  other  two  potential  solutions: 
viewing  the  different  data  items  as  the  same  object  but  with 
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different  attributes  and  considering  the  different  stages 
as  a  new  type  of  object  decomposition. 

The  new  type  of  object  decomposition  was  a  truer  form 
of  decomposition  based  on  the  aggregation  abstraction 
mechanism.  The  underlying  framework  was  too  object- 
or i  e  n  t  e  d  /  c  on  c  e  p  t  u  a  1  modeling-based  to  accommodate 
hierarchical  decomposition  based  on  aggregation.  Therefore, 
the  framework  had  to  be  improved  to  incorporate  this  new 
type  of  decomposition. 

For  continuity  of  presentation,  these  additions  were 
presented  in  Chapter  3  with  the  target  language  description. 
These  included  adding  a  'part-of '  relationship  to  allow  for 
hierarchical  decomposition  based  on  aggregation;  adding  a 
component  property  category  for  both  entities  and  processes; 
changing  the  semantics  of  the  necpart  entity  property 
category  so  that  it  represents  a  static,  fixed,  attribute  of 
an  instance;  and  defining  the  necessary  constraints  to 
properly  support  the  new  form  of  decomposition. 

The  other  component  of  the  solution  involves  viewing 
the  different  data  items  (e.g.,  'patient,'  'evaluated_ 
patient,'  and  ' treated_patient '  )  as  the  same  object  but  with 
different  attributes.  Conceptually,  for  each  instance  of 
'patient'  there  is  just  one  'PERSON'  being  processed.  By 
defining  '  e v al ua t e d_p at ient '  and  '  treat ed_patient  '  as 
components  of  'patient,'  the  semantics  imply  that  an 
instance  of  a  component  is  an  attribute  of  an  instance  of 
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the  aggregate  (i.e.,  an  instance  of  ' evaluated_patient '  is 
an  instance  of  'patient'  with  the  'evaluated'  attribute). 

Recall  that  in  conceptual  modeling  there  are  three 
primitive  operations  used  to  describe  changes  in  the  model: 
create,  destroy,  and  modify.  Create  forms  an  individual  and 
implements  its  membership  in  the  class  and  attribute 
relationships  specified  in  the  operation.  This  operation  is 
implemented  in  RML'  by  the  '  producer '  entity  property 
category.  Destroy  removes  the  individual  from  the  model  and 
from  any  classes  and  attribute  relationships  in  which  it  is 
involved.  This  operation  is  implemented  in  RML'  by  the 
' consumer '  entity  property  category.  Modify  may  involve 
removals  or  additions  to  its  class  memberships  and  attribute 
relations,  in  other  words,  it  modifies  the  individual  in 
some  way.  This  operation  is  implemented  in  RML'  by  the 
' modifier '  entity  property  category. 

Viewing  EVALUATE  and  TREAT  (the  processes  a  'patient' 
undergoes)  as  modifiers  of  'patient'  implies  that  either  the 
individual  class  membership  will  change  (i.e.,  the  patient 
that  was  in  'PATIENT'  will  be  removed  and/or  added  to  some 
new  class  such  as  '  EVALUATED_PATIENT' )  or  that  attribute 
relations  will  change.  Changing  the  class  membership  would 
only  be  a  viable  solution  given  the  new  type  of  object 
decomposition  (i.e.,  ' EVALUATED_PATIENT '  must  be  defined  as 
a  component  of  'PATIENT'  for  'PATIENT'  to  have  'evaluated' 
as  an  attribute). 
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Once  more,  for  continuity  of  presentation,  this 
solution  has  been  incorporated  into  the  methodology  and  was 
discussed  in  Section  4.3  in  terms  of  modeling  the  entity 
structure.  It  was  also  incorporated  into  the  fifth  step 
when  discussing  the  processes  that  modify  an  entity. 
Therefore,  at  this  point  in  the  methodology,  the  life-cycle 
stages  of  an  entity  have  been  modeled  as  components  of  the 
aggregate  entity,  and  those  processes  that  modify  the 
entity  (i.e.,  change  it  from  one  life-cycle  stage  to 
another)  have  been  identified  with  the  appropriate  entity 
(e.g.,  EVALUATE  is  a  modifier  of  'PATIENT'  and  the  attribute 
it  modifies  is  'evaluated;'  see  Figures  9  and  10). 

In  addition  to  modeling  the  stages  as  components  and 
identifying  those  processes  that  modify  the  entity,  one  must 
also  specify  how  the  attributes  get  altered.  As  was  pointed 
out  earlier,  we  maintain  that  the  only  difference  between  a 
'patient'  and  an  ' evaluated_patient '  is  that  the  patient  has 
undergone  the  EVALUATE  process.  We  can  interpret  this  to 
mean  that  the  EVALUATE  process  modifies  the  'evaluated' 
attribute  of  PATIENT.  Thus,  a  PATIENT  has  not  been 
'evaluated'  before  they  experience  the  EVALUATE  process  and 
has  been  'evaluated'  after  they  undergo  the  EVALUATE 
process. 

This  type  of  information  should  be  expressed  as  pre-/ 
postconditions.  Therefore,  for  each  process  that  modifies 
the  entity,  pre-/postconditions  must  be  specified  to  assert 
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that    the    corresponding    attribute    has     the     correct     value. 
This    results    in    the    informal    constraints    specified    in    Figure 
17. 


EVALUATE 

precondition:  patient  not  already  evaluated 

postcondition:  patient  has  been  evaluated 

TREAT 

precondition:  patient  not  already  treated 

postcondition:  patient  has  been  treated 

Figure  17:   Pre-/Postconditions  for  Entity  Life-Cycle  Stage* 


It  has  been  previously  stated  that  the  inherent 
ambiguity  of  dfds  should  be  viewed  as  an  advantageous 
feature  designed  to  prevent  the  analyst  from  introducing  too 
much  detail  early  in  the  analysis  process.  This  inherent 
ambiguity  can  be  illustrated  by  examining  the  data  flow 
junctors.  There  are  only  two  types  of  junctors  that  can  be 
differentiated  by  looking  at  a  dfd  —  branches  and  joins. 
However,  it  is  shown  below  that  these  two  types  actually 
have  several  different  interpretations.  These 
interpretations  are  examined  and  techniques  for  integrating 
their  semantics  into  the  model  are  presented  in  this 
section. 

The  graphical  notations  for  the  two  basic  types  of 
junctors  are  shown  in  Figure  18. 
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B 
C 


A 
B 


Branch  Join 

Figure  18:   Branch  and  Join  Junctors 

The  different  interpretations  of  these  junctors  result 
from  the  possible  relationships  between  A,  Bf  and  C.  Based 
on  these  relationships,  the  dfd  will  be  annotated  with  a 
symbol  at  the  junctor  specifying  which  type  of  junctor  is 
being  represented.  Because  uniformity  is  a  central  feature 
of  our  methodology,  the  relationships  are  based  on 
abstraction  mechanisms.  To  clarify  these  junctors  even 
further,  constraints  are  added  that  specify  the  precise 
semantics.  The  semantics  are  analyzed  and  the  dfd  is 
graphically  annotated  to  reflect  this  analysis  in  this 
step . 

The  semantics  of  the  junctors  are  defined  generically 
as  part  of  the  reusable  core  of  predefined  RML'  constraints 
that  are  specified  in  the  next  step.  A  specific  constraint 
is  added  to  the  model  for  each  junctor  annotated  in  step  7. 

For  the  two  basic  types  of  junctors  shown  in  Figure  18, 
further  clarification  is  needed.  Specifically,  a  junctor 
is  a  Branch  if  it  has  one  input  (inl)  and  two  outputs  (outl 
and  out2);  and  a  junctor  is  a  Join  if  it  has  two  inputs  (inl 
and  in2)  and  one  output  (outl).  These  generics  are  used  to 
express  the  semantics  of  each  interpretation. 
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For  each  dfd  in  the  model,  the  analyst  must  annotate 
each  junctor  to  identify  the  type  of  junctor  being 
represented.   For  each  junctor,  the  analyst  should  specify 
the  following: 

1.  CATEGORY  —  (B  or  J).  Label  either  B  for  branch  or 
J  for  join. 

2.  INTEGER  —  (1  to  n).  Append  to  the  category  label 
to  identify  the  particular  branch  or  join. 

3.  COMPONENTS  —  (inl,  in2,  outl,  out2).  Label  the 
arrows  as  necessary  for  clarity.  Arrow  heads  can 
also  be  added  to  show  the  direction  of  flow  into  or 
out  of  the  junctor. 

4.  OPERATOR  --  (-,  *,  +,  x).  Annotate  the  junctor 
with  the  operator  representing  the  intended 
semantics  (defined  below). 

The  simplest  case  of  each  of  the  two  basic  types  of 
junctors  involves  distributed  data.  The  junctor  simply 
splits  or  joins  duplicate  copies  of  the  same  data  being  sent 
down  two  different  pipes.  To  identify  these  types  of 
junctors,  the  dfd  should  be  annotated  with  the  symbol  "="  to 
show  that  the  data  is  identical  on  all  three  arrows.  The 
semantics  simply  specify  the  desired  equality.  (See  Figure 
19.) 
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(inl) 

A 


(outl) 

A 

A 
"(out2) 


(inl) 
A 


(in2) 


A 
"(outl) 


inl  =  outl 
inl  =  out2 

Distributed  Branch 


inl  =  outl 
in2  =  outl 

Distributed  Join 


Figure  19:   Distributed  Branch  and  Join  Junctors 

Another  pair  of  junctors  is  based  on  the  generalization 
abstraction  mechanism  and  defines  the  is-a  relationship. 
This  relationship  is  between  type  and  subtypes.  It 
corresponds  to  the  set  theoretic  operation  of  'union.'  The 
junctors  either  spread  a  type  into  its  subtypes  or  bundle 
subtypes  into  a  higher-order  type.  To  identify  these  kinds 
of  junctors,  the  dfd  should  be  annotated  with  the  symbol  "+" 
to  show  disjunction.  In  Figure  20  below,  C  is  the  higher- 
order  type,  A  and  B  are  the  subtypes,  and  the  set  theoretic 
description  for  both  junctors  is  C  =  A  U  B.  The  semantics 
are  specified  below  the  diagrams. 
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(outl) 
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B 
'(out2) 


(inl) 
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B 
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C 
"(outl) 


outl  is-a  inl 
out2  is-a  inl 
forall  x  in  inl, 
x  in  outl  or 
x  in  out2 


inl  is-a  outl 
in2  is-a  outl 
forall  x  in  outl , 

x  in  inl  or 

x  in  in2 


Disjunctive  Branch  Disjunctive  Join 

Figure  20:   Disjunctive  Branch  and  Join  Junctors 
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Another  pair  of  junctors  is  also  based  on  the 
generalization  abstraction  mechanism.  However,  these 
junctors  represent  a  specialization  of  the  is-a  relationship 
in  which  the  subtypes  are  disjoint.  To  identify  these  kinds 
of  junctors,  the  dfd  should  be  annotated  with  the  symbol  "x" 
to  show  exclusive  disjunction.  The  intended  semantics  of 
the  junctors  are  given  below  the  diagrams.   (See  Figure  21.) 


(inl) 


(outl) 
A 

B 
"(out2) 


(inl) 
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B 
(in2T 


C 
'(outl) 


outl  is-a  inl 

out2  is-a  inl 

forall  x  in  inl, 
x  in  outl  iff 
not  x  in  out2 

Exclusive  Disjunctive  Branch 


inl  is-a  outl 
in2  is-a  outl 
forall  x  in  outl , 
x  in  inl  iff 
not  x  in  in2 

Exclusive  Disjunctive  Join 


Figure  21:   Exclusive  Disjunctive  Branch  and  Join  Junctors 


Another  pair  of  junctors  is  based  on  the  aggregation 
abstraction  mechanism  and  defines  the  part-of  relationship. 
This  relationship  is  between  aggregate  and  components.  The 
junctors  either  spread  an  aggregate  into  its  components,  or 
bundle  components  into  an  aggregate.  To  identify  these 
kinds  of  junctors,  the  dfd  should  be  annotated  with  the 
symbol  "*"  to  show  conjunction.  The  semantics  of  the 
junctors  are  specified  below  the  diagrams.   (See  Figure  22.) 
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(inl) 


(outl) 
A 

B 
"(out2) 


(inl) 

A 

B 

(in2T" 

outl  part-of  inl 
out2  part-of  inl 
forall  x  in  inl, 
x  in  outl  and 
x  in  out2 


C 
"(outl) 


inl  part-of  outl 
in2  part-of  outl 
forall  x  in  outl, 

x  in  inl  and 

x  in  in2 


Conjunctive  Branch  Conjunctive  Join 

Figure  22:   Conjunctive  Branch  and  Join  Junctors 

Continuing  our  previous  example,  the  dynamic  model 
obtained  in  step  2  must  be  refined  to  reflect  this  new 
information.  Thus,  the  junctors  on  all  dfds  should  be 
annotated  as  specified  above.  The  first  three  steps 
(specifying  the  category,  integer,  and  components)  are 
mechanical  and  result  in  the  the  model  illustrated  in  Figure 
23.  This  preliminary  model  must  be  further  analyzed  to 
correctly  specify  the  operators. 

The  operators  express  the  semantic  information  being 
conveyed  by  the  junctors.  Therefore,  this  step  involves 
supplying  additional  information  to  explain  or  justify  the 
structural  contents  of  the  dfd. 

The  relationship  between  the  inputs  and  outputs  of  each 
junctor  needs  to  be  established.  The  category  and  integer 
form  the  label  of  each  junctor  and  the  components  identify 
the  intended  inputs  and  outputs.  However,  due  to  dfd 
diagramming  conventions,  it  is  not  always  obvious  what  data 
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Figure  23:   Preliminary  Refined  System  Dynamics 
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is  actually  flowing  into  or  out  of  the  junctors.   Therefore, 
for  clarity,  one  might  want  to  identify  the  inputs  and 
outputs  of  each  junctor  separately.   For  our  example,  the 
analysis  would  be  as  follows. 


Bl  :  evaluated  patient< 


evaluated  patient  (to  release) 
evaluated  patient  (to  treat) 


This  branch  is  an  equality  branch  and  has  the  '='  operator. 


B2  :  treated  patient< 


treated  patient  (to  reevaluate) 
treated  patient  (to  release) 


This  branch  is  also  an  equality  branch  and  has  the  '  =  ' 
operator. 

person  (out  of  model) 


B3  :  personX 


person  (to  readmit) 


This  branch  might  be  interpreted  as  'x'  since  the 
junctor  does  split  the  data  into  two  disjoint  groups:  those 
persons  who  exit  from  the  model  and  those  who  will  be 
readmitted  later.  However,  this  branch  is  identical  to  the 
other  two  and  should  also  have  the  '■'  operator.  All  three 
branches  simply  send  identical  copies  of  the  data  down  both 
output  paths.  Recall  that  no  decisions  are  made  at  the 
junctors.  The  preconditions  for  each  process  determine 
which  input  items  are  necessary  for  the  process  to  begin. 
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Jl  :  (new  patient)     person 

>person  (to  admit) 
(former  patient)  person 


Since  former  patients  and  those  persons  that  have  never 
been  a  patient  before  are  disjoint,  this  join  represents 
exclusive  disjunction  and  has  the  'x'  operator. 

J2  :  (admitted)  patient 

>patient  (to  evaluate) 
treated  patient 

This  junctor  bundles  components  into  an  aggregate  and 
has  the  '*'  operator. 


J3  :  evaluated  patient 

>patient 
treated  patient 


Again,  components  are  being  bundled  into  an  aggregate 
and  this  join  has  the  '*'  operator. 

After  each  junctor  has  been  analyzed,  the  resultant 
operators  should  be  added  to  the  dynamic  model.  This  yields 
the  refined  system  dynamic  model  shown  in  Figure  24. 

The  next  set  of  constraints  that  needs  to  be  modeled 
involves  specifying  the  semantics  of  the  temporal 
relationships  between  processes.  To  assist  in  describing 
these  relationships,  a  set  of  predicates  (e.g.,  BEFORE, 
DURING,  MEETS)  is  defined  based  on  [A1183]. 

Recall  that  RML'  has  a  temporal  framework  like  other 
conceptual  modeling  languages.   Time  is  viewed  as  an 
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Figure  24:   Refined  System  Dynamics 
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infinite  and  dense  sequence  of  time  points.   Every  process 
has  an  associated  start  and  end  point  and  the  process  is 
active  between  its  start  and  end  time  points. 

The  temporal  relationships  between  processes  are  often 
implicitly  expressed  in  dfds.  Some  of  these  relationships 
need  to  be  formally  expressed  as  constraints  within  our 
model  while  others  add  unnecessary  inflexibility  to  the 
system  requirements.  Before  we  can  begin  exploration  of 
these  types  of  constraints  we  need  to  define  some  predicates 
for  expressing  temporal  relationships.  These  predicates 
are  informally  defined  in  this  section  and  formalized  in 
the  next  section.   They  include: 

x  During  y  : 

The  time  interval  of  process  x  is 
fully  contained  within  the  time  interval  of 
process  y,  although  they  may  coincide  on  their 
endpoints. 

[    x    ] 

[       y       ] 


x   Before    y    : 

Process  x  is  active  before  process 
y  and  they  do  not  overlap  in  any  way. 

[  x  ]   [  y  ] 
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x  Meets  y  : 

Process  x  is  active  before  process 
y,  but  there  is  no  interval  between  them,  i.e., 
process  x  ends  when  process  y  starts. 


[  x  ] 


[  y  ] 


x  Equal  y  : 

Process  x  and  process  y  are  active 
during  the  same  interval. 

[  x  ] 

[  y  ] 

x  Starts  y  : 

Process  x  begins  at  the  same  time 
as  process  y  but  completes  before  y. 

[  x  ] 

[  y   ] 


x  Finishes  y  : 

Process  x  finishes  at  the  same  time 
as  process  y  but  process  y  starts  before  process 
x. 

[  x  ] 

[   y  ] 
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x  Overlaps  y  : 

Process  x  starts  before  process  y 
and  process  y  starts  before  process  x  ends,  i.e., 
they  share  an  interval. 

[  x  ] 

[  y  ] 


The  constraints  specifying  the  temporal  relationships 
between  processes  utilize  these  predicates  to  describe  what 
has  been  modeled  in  the  dfd.  We  first  examine  some 
different  possibilities  that  might  occur  in  dfds  and 
determine  the  appropriate  constraints.  Guidelines  for 
evaluating  these  constraints  are  then  provided  to  determine 
when    they    should    be    utilized. 

An  example  is  necessary  to  present  this  material. 
Thus,  assume  the  dfd  describes  an  aggregate  process  'P' 
which  consists  of  the  component  processes  'A,'  'B,'  'C,' 
and    'D'     (i.e.,    the    boxes). 

The  Parts-During-Whole  constraints  specify  the  intended 
temporal  semantics  of  the  'part-of '  decomposition.  The 
component  property  category  for  processes  specifies  that  the 
component  process  must  occur  in  order  for  an  instance  of  the 
aggregate  to  occur.  There  are  no  explicit  temporal 
constraints  specifying  what  this  means.  Since  this  temporal 
relationship  is  implicitly  contained  in  dfds  representing 
functional  decomposition,  it  must  be  made  explicit  in  the 
formal    representation. 
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Each     aggregate     process     should     contain     a     'During' 

constraint    for    each    component.       These    are    specified    with    the 

aggregate    process    and    not    with    the    components.       For    our 

example,    this    results    in    the    following    informal    constraints: 


Process  P 

constraints 
A  during  P 
B  during  P 
C  during  P 
D  during  P. 


The  Sequentiali t y  constraints  specify  the  intended 
semantics  of  the  implicit  sequencing  contained  in  dfds. 
Assume  the  typical  dfd  representing  sequential  processing 
from  the  top  left  box  to  the  bottom  right  box  as  in  Figure 
25. 


-* 


4 


-> 


Figure  25:   Sequential  Components  of  Process  P 


There  are  two  distinct  interpretations  of  this  same  dfd 
(and  a  number  of  possible  combinations).  The  first  one  is 
Sometime-Bef ore  and  describes  a  situation  in  which  process 
'A'  occurs  before  process  'B,  '  and  there  is  some  interval  of 
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time     between     the     two     processes.         Assuming     that     this 
relationship    holds    between    the    other    processes    as    well,    the 
following    constraints    apply: 

Process  P 

constraints 
A  before  B 
B  before  C 
C  before  D. 

The  other  interpretation  of  Sequentiality  as  shown  in 
Figure  25  is  that  process  'A'  occurs  before  process  'B'  but 
there  is  no  time  interval  between  them.  This  is  described 
by  the  Immediat ely-Bef or e  constraints  which  describe  a 
situation  in  which  each  preceding  process  triggers  the 
following  process.  Thus  'A'  ends  at  the  exact  time  'B' 
begins.  Again,  assuming  this  relationship  for  the  entire 
dfd,  the  following  constraints  apply: 


Process  P 

constraints 
A  meets  B 
B  meets  C 
C  meets  D. 


Another  set  of  temporal  constraints  applies  to  dfds 
that  model  inherently  nonsequential  processes.  The  Parallel 
constraints  apply  to  dfds  in  which  output  flows  from  'A' 
into  both  'B'  and  'C  processes  as  in  Figure  26. 
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-> 


-) 


Figure  26:   Parallel  Components  of  Process  P 


The  possible  interpretations  will  add  constraints 
involving  the  relationship  between  fB'  and  'C.'  In 
practice  these  might  be  combined  with  constraints  describing 
their  relationships  to  the  other  boxes  as  well. 

The  first  describes  parallel  processes  that  occur 
during  the  same  time  interval.  This  implies  that  they  start 
at  the  same  time  and  end  at  the  same  time.  In  this  case, 
the  constraint  'B  equal  C  would  be  specified  with  the 
aggregate  process  'P.' 

The  second  situation  involves  the  case  where  'B'  and 
'C  begin  at  the  same  time  but  process  'B'  finishes  before 
'C'   The  constraint  'B  starts  C  would  be  specified. 

In  the  third  situation,  'B'  and  'Cf  finish  at  the  same 
time  but  process  'C  starts  before  'B.'  They  are  parallel 
during  the  interval  'B'  is  occurring,  but  there  is  an 
interval  in  which  'C  is  active  and  'B'  is  not.  This  is 
described  by  the  constraint  'B  finishes  C.' 


Ill 

These  are  by  no  means  the  only  temporal  relationships 
that  can  exist  between  processes  modeled  on  a  dfd.  They 
were  presented  here  to  show  the  types  of  situations  that  can 
be  described  using  the  temporal  predicates.  But  perhaps 
more  important  than  what  can  be  specified  with  these 
predicates  is  the  question  of  what  should  be  specified. 

The  modeler  is  cautioned  about  providing  too  many  of 
these  temporal  constraints.  Remember  that  these  are  system 
requirements  that  are  being  developed.  In  other  words, 
these  constraints  must  be  adhered  to  in  the  developed 
system.  Providing  too  many  of  these  temporal  constraints 
decreases  design  flexibility  and  results  in  an  unnecessarily 
rigid  system.  The  following  are  guidelines  for  evaluating 
constraints : 

1.  Do  not  read  too  much  into  the  dfd.  The 
dfd  is  used  to  model  the  structural  contents  of 
the  system.  It  is  inherently  vague  to  allow  for 
interpretation  and  design  flexibility.  It  should 
not  automatically  be  interpreted  as  the  only 
system  decomposition. 

2.  Does  the  dfd  have  to  be  drawn  that  way? 
Consider  alternate  sequencing  of  processes. 
Recall  our  previous  dfd  with  sequential  processes 
'A,'  'B,1  'C,?  and  'D.'  Could  the  dfd  have  been 
drawn  with  the  data  flowing  from  'A'  to  'C  and 
from  'C  to  'B?1   Given  the  first  ordering,  the 
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constraint  'B  before  C  might  have  been  specified. 
Is  there  something  about  the  system  that  requires 
'B  before  C'  or  are  the  constraints  simply 
describing  the  dfd? 

In  our  hospital  example,  the  top  level  dfd 
('BE_A_HOSPITAL_PATIENT'  as  shown  in  Figure  4) 
describes  a  situation  in  which  a  person  is 
admitted,  becomes  evaluated,  then  is  treated,  and 
finally  is  released.  We  would  not  want  to  alter 
the  sequencing  here  (i.e.,  we  do  not  want  the 
patients  treated  before  their  initial  evaluation). 
On  the  other  hand,  consider  a  lower  level 
decomposition  of  the  pretests  that  are  done  as 
part  of  the  admitting  procedure.  These  include 
urinalysis  and  taking  the  patient's  blood  count, 
blood  pressure,  and  temperature.  Regardless  of 
how  these  may  be  sequenced  on  a  dfd,  these  tests 
may  be  given  in  any  order  with  the  actual  order 
probably  depending  on  outside  factors  (e.g.,  a 
particular  nurse's  habit).  Temporal  constraints 
should  be  added  for  the  top  level  dfd  and  should 
not  for  the  lower  level  dfd. 

3.  Carefully  evaluate  the  role  of  time  within 
the  system.  If  the  modeler  is  uncertain  about  the 
amount  of  time  that  may  pass  between  processes,  it 
is  best  not  to  add  constraints.   For  example,  it 
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may  be  unclear  whether  one  process  is  Before 
another  (i.e.,  some  interval  occurs  between  them) 
or  Meets  the  other  (i.e.,  the  end  of  the  first 
triggers  the  start  of  the  second).  In  this  case, 
either  no  constraints  should  be  specified  or  the 
looser  constraint  stating  that  either  the  first 
process  is  Before  the  second  or  the  first  process 
Meets  the  second  should  be  specified. 

4.  If  it  is  not  absolutely  necessary  for  the 
proper  interpretation  of  the  dfd,  do  not  include 
it.  Try  to  keep  the  system  requirements  as 
flexible  as  possible. 

Continuing  our  hospital  example,  the  applicable 
constraints  are  informally  specified  as  in  Figure  27. 
Recall  that  the  'Parts-Bef ore- Whole'  constraints  are 
specified  with  the  aggregate  (e.g.,  '  BE_A_HOSPITAL_ 
PATIENT').  The  specific  components  are  added  in  the  next 
step  when  the  constraints  are  refined. 

Recall  that  the  ' Sometime-Bef ore '  constraints  refer  to 
the  typical  sequential  dfd  in  which  each  component  occurs 
Before  the  next.  Like  the  above  constraints,  these  are 
specified  with  the  aggregate,  informally  stated  in  this 
step,  and  formally  refined  in  the  next  step. 
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BE_A_HOSPITAL_PATIENT 
constraints : 

Parts-During-Whole 
Some time-Be fore 

EVALUATE 

constraints : 

Parts-During-Whole 
Some time-Before 

Figure    27:      Preliminary   Temporal    Constraints 


4.7.3      Model    Entity    Behavior 

This  task  involves  modeling  entity  behavior  that  is  not 
addressed  in  the  previous  steps.  This  includes  adding 
information  pertaining  to  initial  conditions,  final 
conditions,    and    invariants. 

Initial  conditions  are  constraints  that  must  be  true 
when  an  object  becomes  an  instance  of  the  entity  class. 
Final  conditions  are  constraints  that  must  be  true  at  the 
time  an  object  ceases  to  be  an  instance  of  the  entity  class. 
Invariants  are  constraints  that  are  always  true  of  an 
instance    of    the    entity    class. 

This  step  specifies  these  constraints  informally.  The 
informal  statements  are  formalized  in  the  next  step. 
Continuing  our  previous  example,  the  additional  entity 
constraints  that  must  be  specified  are  shown  in  Figure  28. 
These  constraints  apply  to  the  'CHILD'  entity  and  they 
restrict    a    child's    age    and    the    age    of    a    child's    guardian. 
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CHILD 

constraints : 

a  child's  age  must  be  under  18 
a  child's  guardian  must  be  at  least 
21  years  old 

Figure  28:   Preliminary  Entity  Constraints 

This  layer  of  the  model  should  identify  the  following: 

a.  interface  operators; 

b.  activation  rules; 

c.  elementary  processes; 

d.  triggering  conditions,  preconditions,  and 
postconditions  from  activation  rules  and 
elementary    process    decompositions; 

e.  data    flow   junctor    operators; 

f.  temporal    ordering    of    processes;    and 

g.  entity    behavior. 

4.8  Specify  Constraints 
This  step  involves  modeling  the  constraints  that  need 
to  be  added  to  the  object  definitions  identified  previously. 
RML  constraints  are  expressed  using  an  assertion  sublanguage 
that  combines  a  number  of  predefined  predicates  (e.g.,  IN, 
ISA,  =)  with  a  full  First-Order  Logic.  Specifying  these 
constraints  in  RML  is  a  tedious  task.  The  fact  that  the 
abstraction  mechanisms  can  be  used  to  organize  the 
constraints  should  help  in  defining  them,  but  due  to  the 
difficulty  of  the  syntax,  that  is  not  necessarily  the  case. 
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The     goal     of     this     step     is     to    assist     the    analyst    in 
specifying      these      constraints.  This      is      done      by 

incrementally  refining  the  information  and  using  a 
predefined  core  of  reusable  objects/constraints.  This  set 
of  objects  assists  in  describing  the  structural  information 
contained  in  the  dfds  that  is  typically  lost  at  the 
specification  level  (e.g.,  the  information  conveyed  by  the 
junctors).  It  also  assists  in  formally  describing  the 
temporal  relationships  between  processes  and  includes  the 
definitions  of  a  set  of  temporal  predicates  (e.g.,  BEFORE, 
DURING,  MEETS)  as  in  [A1183].  Finally,  it  refines  any 
preliminary  entity  constraints  that  were  provided  in  the 
previous    step. 

4.8.1      Model    Internal    Process    Constraints 

The  first  task  involves  modeling  the  internal  process 
constraints.  This  requires  defining  a  constraint  object  for 
each  triggering  condition,  precondition,  and  postcondition 
identified  in  step  7.  Any  other  relevant  constraints 
(e.g.,    stopping    conditions)    should    be    added    at    this    point. 

Continuing  the  previous  example,  this  step  defines 
constraint  objects  corresponding  to  the  phrases  used  in  the 
act-/pre-/postconditions  in  Figure  16.  The  RML'  constraint 
objects  and  the  act-/pr e-/postcondi tions  in  the  above 
example    are    given    in   Figure    29. 

Recall  that  the  phrases  used  in  the  previous  step 
typically    involve    stating    or    negating     related     assertions, 
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The  RML'  constraint  objects  are: 

A_PATIENT?  in  CONSTRAINT_CLASS  with 
argument 

person:   PERSON 
part 

patient?:   IN  (person,  PATIENT) 

R00M_LEFT  in  CONSTRAINT_CLASS  with 
constraint 

room?:   PATIENT. cardinality  <  PATIENT_MAX* 

IN_HOSPITAL  in  CONSTRAINT_CLASS  with 

argument 

person:   PERSON 

part 

patient?:   A_PATIENT? (person) 

present? :   PHYSICALLY_PRESENT(person)** 


The  act-/pre-/postconditions  are  refined  to: 

ADMIT 

actcond 

arrival:   ARRIVAL(person)** 
precondition 

already_in?:   not   A_PATIENT(person) 

available_room? :  ROOM_LEFT 
postcondition 

admitted?:  IN_HOSPITAL(person) 

REJECT_ADMISSION 
actcond 

arrival:   ARRIVAL(person) 
precondition 

already_in?:   A_PATIENT(person) 
available_room?:   not  ROOM_LEFT 
postcondition 

admitted?:   not  IN_HOSPITAL( person) 


*PATIENT_MAX  is  assumed  to  hold  the  value  of  the 
maximum  number  of  patients  allowed  in  the  hospital 

**ARRIVAL  and  PHYSICALLY_PRESENT  are  considered 
primitive . 


Figure  29:   RML'  Constraints  and  Act-/Pre-/Postcondition; 
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specifying  the  arrival  of  an  object,  and  asserting  that  an 
object  is  or  is  not  in  another  object.  Disregarding 
negation,  the  phrases  used  in  Figure  16  were  'person 
arrives,1  'person  already  a  patient,'  'room  left,'  and 
'person  in  hospital.' 

As  stated  in. Figure  29,  'ARRIVAL'  is  considered 
primitive  and  thus  the  formal  translation  of  the  activating 
condition  is  ' ARRIVAL(person)  .  '  'Person  already  a  patient' 
is  defined  as  the  constraint  object  'A_PATIENT?'  which  uses 
the  built-in  predicate  'IN'  to  verify  that  'person'  is  an 
instance  of  'PATIENT.1  'ROOM_LEFT'  verifies  that  there  is 
available  room  in  the  hospital  by  comparing  the  metaclass 
'cardinality'  property  of  'PATIENT'  with  the  maximum  number 
of  patients  allowed  in  the  hospital.  'Person  in  hospital' 
is  defined  to  verify  not  only  that  'person'  is  an  instance 
of  'PATIENT,'  but  also  that  'person'  is  physically  present 
(i.e.,  what  is  generally  meant  by  being  "in  the  hospital"). 

These  constraint  objects  are  then  asserted  (e.g., 
'R00M_LEFT')  or  negated  (e.g.,  'not  R00M_LEFT')  in  the  act- 
/pre-/postconditions  of  the  processes. 

4.8.2   Model  External  Process  Constraints 

The  next  task  is  to  model  the  external  process 
constraints.  This  consists  of  defining  a  constraint  object 
for  each  data  flow  junctor  operator  used,  each  temporal 
ordering  identified,  and  each  constraint  describing  the 
life-cycle  stages  of  entities  identified  in  step  7. 
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Before  we  can  begin  discussing  this  task,  we  must 
clarify  the  issues  involved.  The  question  at  hand  focuses 
on  the  knowledge  representation  being  utilized  and  the 
precise  knowledge  being  conveyed  by  that  representation. 

The  dynamics  of  the  model  have  been  described  using 
dfds.  The  language  of  dfds  consists  of  boxes,  arrows,  and 
junctors.  Until  now,  we  have  assumed  that  the  dfd  was  a 
kind  of  "visual  aid"  for  understanding  the  contents  of  the 
model  (i.e.,  the  domain  of  discourse).  This  is  absolutely 
correct.  However,  at  this  point  we  must  transform  the 
information  conveyed  in  the  dfds  into  a  formal 
specification.  This  raises  the  question  of  whether  we  need 
to  model  the  contents  of  the  dfd,  the  dfd  itself,  or  both. 
That  is,  do  we  restrict  ourselves  to  describing  the  domain 
of  discourse  (e.g.,  a  hospital),  do  we  describe  the  model 
in  terms  of  the  components  of  the  dfd  (e.g.,  the  boxes  and 
arrows),  or  do  we  need  to  describe  both? 

This  issue  may  appear  simplistic,  but  this  author 
believes  that  it  is  precisely  this  simplistic  appearance 
that  causes  analysts  to  overlook  this  question  entirely. 
Furthermore,  when  this  question  is  overlooked,  the  resultant 
specification  loses  valuable  information. 

Intuitively,  one  believes  that  the  dfd  is  merely  a  tool 
for  understanding  the  contents  of  the  model.  Thus,  since 
the  domain  of  discourse  is  being  modeled,  that  information 
should  be  the  basis  for  refinement  in  the  specification. 
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Therefore,  describing  the  boxes  and  arrows  of  the  dfd  at  the 
requirements  specification  level  seems  somewhat  contrived. 
However,  the  dfd  models  structural  information  that  is 
difficult  to  describe  using  only  the  terms  of  the  domain  of 
discourse.   In  other  words,  the  dfd  abstraction  provides 
knowledge  about  the  relationships  between  the  data  items  and 
the  processes  that  contributes  to  the  understanding  of  the 
domain.    This  information  is  considered  the  implicit 
information  contained  in  dfds  that  is  typically  lost  during 
the  specification  process  due  to  the  fact  that  the  dfd 
abstraction  is  abandoned  at  the  requirements  analysis  level. 
The  solution  to  this  problem  is  very  much  in  line  with 
conceptual  modeling  theory  and  involves  incorporating 
multiple  views  into  the  model.   Specifically,  restricting 
our  model  to  the  domain  of  discourse  results  in  lost 
information.    On  the  other  hand,  describing  the  domain 
entirely  in  terms  of  the  dfd  results  in  specifications  in 
which  the  objects  of  the  model  are  boxes  and  arrows  rather 
than  objects  in  the  domain  (e.g.,  patients,  physicians, 
etc.).    Therefore,  viewing  the  model  at  both  levels  of 
abstraction  and  incorporating  those  views  into  the  model 
provides  a  thorough  requirements  specification  in  which  all 
of  the  information  that  was  described  at  the  analysis  level 
is  explicit  and  formal. 

To  be  able  to  view  the  model  in  terms  of  the  dfd  we 
must  first  define  those  terms  at  the  RML*  level.    This 
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constitutes  the  first  part  of  the  reusable  core  of  RML' 
object  definitions.    Specifically,  we  define  a  dfd 
metaclass,  DFD,  as  shown  in  Figure  30. 

DFD  in  PROCESS_METACLASS  with 
component 

boxl:   CLASS 

box2:   CLASS 

box3:   CLASS 

box4:   CLASS 

box5:   CLASS 
input 

il:   CLASS 

12:   CLASS 

i3:   CLASS 

i4:   CLASS 

15:   CLASS 
output 

ol:   CLASS 

o2:   CLASS 

o3:   CLASS 

o4:   CLASS 

o5:   CLASS 
control 

cl:   CLASS 

c2:   CLASS 

c3:   CLASS 

c4:   CLASS 

c5:   CLASS 

Figure  30:   DFD  Metaclass  Definition 

Within  the  DFD  definition,  the  property  values  are  all 
defined  to  be  the  built-in  metaclass  CLASS  which  contains 
all  other  classes.  Even  though  we  know  that  the  components 
will  be  processes  and  the  inputs,  outputs,  and  controls 
will  be  entities,  we  can  not  define  the  property  values  any 
more  r estr icti vely  because  the  actual  property  values  are 
usually  user-defined  classes. 
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The  dfds  in  the  model  are  defined  as  instances  of  this 
DFD  metaclass.  Therefore,  by  the  property  induction 
constraint,  factual  properties  are  induced  for  each 
definitional  property  of  DFD  and  the  value  of  each  is  an 
instance  of  CLASS  or  null.  Thus,  each  instance  of  DFD  has 
induced  factual  properties  boxl,  box2,  box3,  etc. 

Now  that  we  have  defined  a  generic  DFD  metaclass,  we 
must  define  each  dfd  in  the  model  as  an  instance  of  this 
metaclass  and  provide  constraints  that  specify  what  the 
actual  property  values  are.  In  other  words,  the  constraints 
define  the  correspondence  between  the  generic  properties  of 
the  DFD  metaclass  and  the  specific  properties  of  the  process 
being  described  by  the  dfd.  This  correspondence  allows  us 
to  refer  to  the  same  property  by  two  names,  that  is,  it 
provides  alternative  views  of  the  same  model. 

To  enable  different  views  of  an  object,  we  must  define 
the  object  as  an  instance  of  more  than  one  class.  In  Figure 
31,  the  object  being  defined,  BE_A_HOSPITAL_PATIENT ,  is 
defined  as  an  instance  of  PROCESS_CLASS  (since  it  is  a 
process  that  is  being  described)  and  as  an  instance  of  DFD, 
our  generic  metaclass  providing  the  dfd  structural 
components. 

The  correspondence  is  defined  using  the  factual 
property  selection  function.  To  understand  how  this  works, 
consider  the  'si'  property: 

DFD.il  =  person 
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BE_A_HOSPITAL_PATIENT  in  PROCESS_CLASS ,  DFD  with 
input 

person:   PERSON 
output 

person:   PERSON 
control 

ward:   HOSPITAL_WARD 

physician:   PHYSICIAN 

consulting_physician:   PHYSICIAN 
component 

admit:   ADMIT 

evaluate:   EVALUATE 

treat:   TREAT 

release:   RELEASE 
constraint 

si:   DFD.il  =  person 

s2:   DFD.ol  =  person 

s3:   DFD.cl  =  ward 

s4:   DFD.c2  =  physician 

s5:   DFD.c3  =  consulting_physician 

s6:   DFD.boxl  -  admit 

s7:   DFD.box2  =  evaluate 

s8:   DFD.box3  -  treat 

s9:   DFD.box4  ■  release 

Figure  31:   RMLf  Object  Definition  with  a  Dfd  View 


This  constraint  states  that  the  '11'  factual  property  value 
of  DFD  is  the  same  as  'person.'  Therefore,  the  input 
properties  'person'  and  'il'  of  BE_A_HOSPITAL_PATIENT  are 
equivalent  and  both  have  the  value  'PERSON.' 

The  generic  DFD  is  the  basis  for  a  set  of  reusable 
constraint  objects  that  we  define  to  describe  possible 
relationships  between  data  and  processes  that  are  modeled  in 
the  dfds.  The  specific  object  definitions  for  individual 
dfd  objects  contain  constraints  referencing  this  generic 
core. 

Figure  31  shows  the  RML'  object  definition  of 
BE_A_HOSPITAL_PATIENT.   It  is  presented  here  to  clarify  the 
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correspondence  between  the  generic  properties  of  the  DFD  and 
the  specific  properties  of  an  individual  activity.  In  the 
actual  modeling  process,  the  RML1  definition  will  not  be 
presented  until  step  9.  At  this  point,  the  semantics  have 
been  presented  graphically.  This  step  provides  the 
definitions  of  constraints  that  need  to  be  added  to  the 
graphic  model.  Therefore,  the  first  set  of  constraints  that 
needs  to  be  defined  sets  up  the  DFD  correspondence.  For  our 
example,  this  involves  specifying  the  DFD  constraints  with 
their  appropriate  dfd  object  definition.  This  yields  the 
constraints  as  specified  in  Figure  32. 

BE_A_HOSPITAL_PATIENT  in  DFD 
constraint 

si:   DFD.il  =  person 

s2:   DFD.ol  =  person 

s3:   DFD.cl  =  ward 

s4:       DFD.c2    ■    physician 

s5:       DFD.c3    =    consulting_physician 

s6:      DFD.boxl    =   admit 

s7:      DFD.box2    =    evaluate 

s8:      DFD.box3    =    treat 

s9:      DFD.box4   =    release 

Figure    32:      RML'    Object    Specification    of   Dfd    Constraints 

The  second  set  of  constraints  that  needs  to  be  defined 
involves  formalizing  the  semantics  of  the  data  flow  junctors 
described  in  the  previous  section.  A  reusable  set  of 
constraint  objects  are  defined  for  expressing  these 
constraints. 

Two  metaclasses  are  defined  for  organizing  the 
constraints,     BRANCH    and    JOIN.        (See    Figure    33.)        These    two 


125 

BRANCH  in  CONSTRAINT_METACLASS  with 
arguments 

inl:   CLASS 
outl:   CLASS 
out2:   CLASS 

JOIN  in  CONSTRAINT_METACLASS  with 
arguments 

inl:  CLASS 
in2:  CLASS 
outl:   CLASS 

Figure  33:   BRANCH  and  JOIN  Metaclasses 


metaclasses  simply  specify  the  arguments  as  illustrated  in 
Figure  18.  Specifically,  a  branch  is  a  junctor  with  one 
input  and  two  outputs,  and  a  join  is  a  junctor  with  two 
inputs  and  one  output.  The  property  values  are  defined  to 
be  the  general  built-in  metaclass  CLASS  to  allow  for  user- 
defined  classes. 

The  arguments  are  simply  definitional  properties  and 
consequently  are  inherited  by  'is— a'  related  specialized 
metaclasses.  Thus  when  specifying  the  specializations,  one 
may  refer  directly  to  the  argument  properties  (e.g.,  'inl'). 
The  actual  values  for  these  arguments  are  specified  as 
constraints  with  the  dfd  in  which  they  exist. 

The  distributed  junctors  (illustrated  in  Figure  19)  are 
defined  as  specializations  of  these  metaclasses  as  shown  in 
Figure  34.  These  constraints  describe  junctors  in  which 
identical  copies  of  the  data  exist  on  the  inputs  and  outputs 
of  the  junctor. 
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DISTRIBUTED_BRANCH  isa  BRANCH  with 
constraint 

equal:   inl  =  outl  AND 
inl  »  out2 

DISTRIBUTED_JOIN  isa  JOIN  with 
constraint 

equal:   inl  ■  outl  AND 
in2  =  outl 

Figure  34:   DISTRIBUTED  BRANCH  and  JOIN  Metaclasses 


The  disjunctive  junctors  (illustrated  in  Figure  20)  are 
also  defined  as  specializations  of  the  BRANCH  and  JOIN 
metaclasses  as  given  in  Figure  35.  Note  that  the  outputs 
and  inputs  of  the  junctors  are  'is-a'  related  and  the  built- 
in  predicate  'ISA1  is  used  to  express  this  information. 


DISJUNCTIVE_BRANCH  isa  BRANCH  with 
constraint 

ol-isa-inl:  outl  ISA  inl 
o2-isa-inl:  out2  ISA  inl 
union:   FORALL  x  IN  inl 

[(x  IN  outl)  OR 
(x  IN  out2)] 

DISJUNCTIVE_JOIN  isa  JOIN  with 
constraint 

inl-isa-ol:  inl  ISA  outl 
in2-isa-ol:  in2  ISA  outl 
union:   FORALL  x  IN  outl 

[(x  IN  inl)  OR 
(x  IN  in2)] 

Figure  35:   DISJUNCTIVE  BRANCH  and  JOIN  Metaclasses 


The  exclusive  disjunctive  junctors  (illustrated  in 
Figure  21)  are  also  defined  as  specializations  of  the  BRANCH 
and  JOIN  metaclasses  as  specified  in  Figure  36.   Note  the 
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EXCLUSIVE_DISJUNCTIVE_BRANCH  isa  BRANCH  with 
constraint 

ol-isa-inl:  outl  ISA  inl 
o2-isa-inl:  out2  ISA  inl 
ex-or:   FORALL  x  IN  inl 

[(x  IN  outl)  IFF 
NOT  (x  IN  out2)] 

EXCLUSIVE_DISJUNCTIVE_JOIN  isa  JOIN  with 
constraint 

inl-isa-ol:  inl  ISA  outl 
in2-isa-ol:  in2  ISA  outl 
ex-or:   FORALL  x  IN  outl 

[(x  IN  inl)  IFF 
NOT  (x  IN  in2)] 

Figure  36:   EXCLUSIVE  DISJUNCTIVE  BRANCH  and  JOIN  Metaclasses 


use  of  the  built-in  predicate  'IN'   and  the  logical 
connective  'IFF.1 

The  conjunctive  junctors  (illustrated  in  Figure  22)  are 
also  defined  as  specializations  of  the  BRANCH  and  JOIN 
metaclasses  as  shown  in  Figure  37.  These  constraints  use 
the  built-in  predicate  'PARTOF'  to  describe  the  component/ 
aggregate  relationship. 


CONJUNCTIVE_BRANCH  isa  BRANCH  with 
constraint 

ol-part-inl:  outl  PARTOF  inl 
o2-part-inl:  out2  PARTOF  inl 
components:   FORALL  x  IN  inl 

[(x  IN  outl)  AND 
(x  IN  out2)] 

CONJUNCTIVE_JOIN  isa  JOIN  with 
constraint 

inl-part-ol:  inl  PARTOF  outl 
in2-part-ol:  in2  PARTOF  outl 
components:   FORALL  x  IN  outl 

[(x  IN  inl)  AND 
(x  IN  in2)] 

Figure  37:   CONJUNCTIVE  BRANCH  and  JOIN  Metaclasses 
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Note  the  use  of  the  generalization  abstraction 
mechanism  to  organize  these  constraints.  Specifying  each  of 
these  classes  as  a  subtype  of  the  BRANCH  or  JOIN  metaclasses 
allows  the  inheritance  of  the  arguments.  This  organization 
simplifies  the  constraints  and  clarifies  their  semantics. 

These  metaclasses  are  utilized  by  specifying  their 
arguments  and  including  them  as  constraints  in  their  dfd 
object  definitions.  Continuing  our  example,  the  RML'  object 
definition  for  ' BE_A_HOSPITAL_PATIENT'  as  shown  in  Figure  31 
has  an  additional  constraint  object  specified  for  each 
junctor  annotated  on  the  refined  system  dynamic  model  shown 
in  Figure  24.  The  arguments  are  specified  using  the  generic 
dfd  property  names  since  the  constraints  are  conveying 
structural  information.   (See  Figure  38.) 

Recall  that  the  factual  property  selection  function 
refers  to  the  value  of  the  specified  property.  For  example, 
consider  the  'b3'  property: 

Equality  Branch  (inl:   box4.ol;  outl:  ol;  out2:  jl.in2). 

The  'inl'  argument  (which  is  also  a  property)  has  the 
value  'box4.ol'  which  refers  to  the  value  of  the  'ol' 
property  of  'box4.'  'Box4'  is  equivalent  to  the  'release' 
property  by  the  's9'  constraint.  Therefore,  'box4.olf  is 
referring  to  the  output  property  of  the  dfd  decomposition  of 
release'  which  is  a  lower  level  decomposition  (since 
'release'  is  a  component  of  ' BE_A_HOSPITAL_PATIENT '  and 
components  are  decomposed  at  the  next  dfd  level). 
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BE_A_HOSPITAL_PATIENT  in  PROCESS_CLASS ,  DFD  with 
input 

person:   PERSON 
output 

person:   PERSON 
control 

ward:   HOSPITAL_WARD 
physician:   PHYSICIAN 
consulting_physician:   PHYSICIAN 
component 

admit:   ADMIT 
evaluate:   EVALUATE 
treat:   TREAT 
release:   RELEASE 
constraint 

si:   DFD.il  =  person 

s2:   DFD.ol  =  person 

s3:   DFD.cl  =  ward 

s4:   DFD.c2  =  physician 

s5:   DFD.c3  =  consulting_physician 

s6:   DFD.boxl  =  admit 

s7:   DFD.box2  =  evaluate 

s8:   DFD.box3  =  treat 

s9:   DFD.box4  =  release 

jl:   Exclusive  Disjunctive  Join  (inl:   il; 

in2:   b3.out2; 
outl:  boxl.il) 
j2:   Conjunctive  Join  (inl:   boxl.ol; 

in2:   b2.outl; 

outl:  box2.il) 

j3:   Conjunctive  Join  (inl:   bl.outl; 

in2:   b2.out2; 
outl:  box4.il) 
bl:   Equality  Branch  (inl:   box2.ol; 

outl:  j3.ini; 
out2:  box3.il) 
b2:   Equality  Branch  (inl:   box3.ol; 

outl:  j2.in2; 
out2:  j3.in2) 
b3:   Equality  Branch  (inl:   box4.ol; 

outl :  ol ; 
out2:  jl.in2) 

Figure  38:   RML1  Object  Definition  with  Junctor  Constraints 


The  'outl'  argument  has  the  value  'ol,'  which  by  the 
's2'  constraint  is  equivalent  to  the  'person'  property  and 
has  the  value  'PERSON.' 
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The  'out2'  argument  has  the  value  'jl.in2.'   This  says 
that  the  factual  property  values  of  the  'in2'  property  of 
'jl'  and  the  'out2'  property  of  'b3'  are  equivalent. 

Figure  38  shows  the  RML'  object  definition  of 
'BE_A_HOSPITAL_PATIENT.f  It  is  presented  here  to  clarify 
the  usage  of  the  generic  properties  of  the  dfd  in  the 
junctor  constraint  properties.  Once  again,  in  the  actual 
modeling  process,  the  RML1  definition  is  not  presented 
until  step  9.  The  current  step  provides  the  definitions  of 
constraints  that  are  added  to  the  previously  defined 
graphic  model.  Therefore,  the  second  set  of  constraints 
that  needs  to  be  defined  models  the  dfd  junctors.  This 
involves  specifying  the  junctor  constraints  with  their 
appropriate  dfd  object  definition.  For  our  example  this 
yields  the  constraints  as  specified  in  Figure  39. 


BE_A_HOSPITAL_PATIENT  in  DFD 
constraint 

jl:   Exclusive  Disjunctive  Join  (inl:   il; 

in2:   b3.out2; 
outl:  boxl.il) 
j2:   Conjunctive  Join  (inl:   boxl.ol; 

in2:   b2.outl; 

outl:  box2.il) 

j3:   Conjunctive  Join  (inl:   bl.outl; 

in2:   b2.out2; 
outl:  box4.il) 
bl:   Equality  Branch  (inl:   box2.ol; 

outl :  j  3  .inl ; 
out2:  box3.il) 
b2:   Equality  Branch  (inl:   box3.ol; 

outl:  j2.in2; 
out2:  j3.in2) 
b3:   Equality  Branch  (inl:   box4.ol; 

outl :  ol ; 
out2 :  j 1  .in2) 

Figure  39:   RML1  Object  Specification  of  Junctor  Constraints 


131 

The  third  set  of  constraint  objects  that  needs  to  be 
defined  involves  formalizing  the  semantics  of  the  temporal 
relationships  between  processes.  To  assist  in  describing 
these  relationships,  a  set  of  predicates  (e.g.,  BEFORE, 
DURING,  MEETS)  are  defined  based  on  [A1183]. 

Recall  that  in  RML'  (and  RML)  a  process  is  active 
between  its  start  and  stop  time  points.  Thus,  every  process 
has  associated  start  and  stop  times.  Two  functions  have 
been  defined  to  access  these  values: 

START(x)  :   yields  the  start  time  of  process  x,   and 

END(x)  :   yields  the  stop  time  of  process  x. 
Furthermore,  a  process  is  an  instance  of  a  class  between  the 
start  and  end  times.   The  IN  predicate  asserts  that  an 
object  is  an  instance  of  a  class.   It  may  be  specified 
without  giving  a  time  argument  as  in: 

IN(x,y)  :   asserts  object  x  is  an  instance  of  class  y. 
This  implies  that  x  is  in  y  whenever  necessary.   Or  it  may 
be  specified  with  a  time  argument  as  in: 

IN(x,y,z)  :   asserts  object  x  is  an  instance  of  class  y 
at  time  z. 
In  terms  of  the  previous  predicates,  we  have: 

IN(x,y,z)  <=>  START(x)  <=  z  <=  END(x). 

Formalizing  the  temporal  predicates  defined  in  the 
previous  section  yields  the  following  definitions: 
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DURING(x.y)    <=> 

START(y)    <=    START(x)    AND 

END(x)    <=   END(y) 

[    x    ] 
[  7  ] 

BEFORE(x.y)    <=> 

END(x)    <    START(y) 
[    x    ]       [    y    ] 

MEETS(x,y)    <=> 

END(x)    =    START(y) 

[    x    ] 

[    7    ] 

EQUAL(x.y)    <=> 

START(x)    =    START(y)    AND 

END(x)    =    END(y) 

[     x    ] 
[    y    ] 

STARTS(x,y)    <=> 

START(x)    -    START(y)    AND 
END(x)    <    END(y) 
[    x    ] 

[   y       ] 
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FINISHES(x,y)  <=> 

END(x)  =  END(y)  AND 

START(y)  <  START(x) 

[  x  ] 
[    7  ] 

OVERLAPS(x,y)  <=> 

START(x)  <  START(y)  AND 

START(y)  <  END(x) 

[  x  ] 
[  7  1 

For  each  temporal  constraint  informally  specified  in 
step  7,  a  formal  constraint  must  now  be  added.  Expand  the 
constraints  into  their  component  objects  based  on  their 
definitions  as  necessary  (e.g.,  ' Pa r t s-Dur ing-Wh o 1 e ' 
consists  of  'A  During  B,'  'B  During  C,'  etc.).  Formalize 
each  constraint  object  using  the  following  mapping: 

x  During  y  ==>   DURING(x,y); 

x  Before  y  ==>   BEFORE(x,y); 

x  Meets  y  ==>   MEETS(x,y); 

x  Equal  y  ==>   EQUAL(x,y); 

x  Starts  y  ==>   STARTS(x,y); 

x  Finishes  y  ==>   FINISHES(x , y) ;  and 

x  Overlaps  y  ==>   OVERLAPS(x , y ) . 

Continuing  our  hospital  example,  the  informal 
constraints  specified  in  Figure  27  are  refined  and  specified 
in    Figure    40. 
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BE_A_HOSPITAL_PATIENT    with 
constraint 


DURING    (ADMIT,    BE_A_HOSPITAL_PATIENT) ; 
DURING    (EVALUATE,    BE_A_HOSPITAL_PATIENT) ; 
DURING    (TREAT,    BE_A_HOSPITAL_PATIENT) ; 
DURING    (RELEASE,    BE_A_HOSPITAL_PATIENT) ; 
BEFORE    (ADMIT,    EVALUATE); 
BEFORE    (EVALUATE,    TREAT); 
BEFORE    (TREAT,    RELEASE); 


EVALUATE   with 

constraint 


DURING    (EXAMINE,    EVALUATE); 
DURING    (TEST,    EVALUATE); 
DURING    (ASSESS,    EVALUATE); 
BEFORE    (EXAMINE,    TEST); 
BEFORE    (TEST,    ASSESS); 

Figure    40:       RML'    Temporal    Constraints 


The  next  task  is  to  model  the  entity  life-cycle 
constraints.  This  consists  of  defining  a  constraint  object 
for  each  precondition  and  postcondition  for  entity  life- 
cycle    stages    identified    in    step    7. 

Continuing  the  previous  example,  this  step  defines 
constraint  objects  corresponding  to  the  phrases  used  in  the 
pre-/postconditions  in  Figure  17.  The  RML'  constraints  are 
given    in    Figure    41. 

Recall  that  the  phrases  used  in  the  previous  step 
involved  stating  or  negating  related  assertions. 
Disregarding  negation,  the  phrases  used  in  Figure  17  were 
'patient    already    evaluated'    and    'patient    already    treated.' 
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EVALUATED?  in  CONSTRAINT_CLASS  with 
argument 

patient:   PATIENT 
part 

evaluated:   IN  (patient,  EVALUATED_PATIENT) 

TREATED?  in  CONSTRAINT_CLASS  with 
argument 

evaluated_patient:   EVALUATED_PATIENT 
part 

treated?:   IN  (evaluated_patient ,  TREATED_PATIENT) 


The  act-/pre-/postconditions  would  be  refined  to: 

EVALUATE 

precondition 

already_evaluated?:   not  EVALUATED? (patient) 
postcondition 

evaluation_complete?:  EVALUATED? (patient) 

TREAT 

precondition 

already_treated?:       not    TREATED? (evaluated) 
postcondition 

treatment_complete?:    TREATED? (evaluated) 

Figure    41:      RML*    Constraints    for    Entity   Life-Cycle    Stages 


'Patient  already  evaluated'  is  defined  as  the 
constraint  object  'EVALUATED?'  which  uses  the  built-in 
predicate  'IN'  to  verify  that  'patient'  is  an  instance  of 
'EVALUATED_PATIENT.  '  Similarly,  'TREATED?'  verifies  that 
'evaluated_patient  '  is  an  instance  of  '  TREATED_PATIENT .  ' 
The  pr e-/pos tcondi tions  simply  assert  or  negate  the 
previously    defined    constraints. 
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4.8.3   Model  Entity  Constraints 

This  task  formalizes  the  entity  constraints 
representing  initial  conditions,  final  conditions,  and 
invariants  that  were  identified  in  step  7.  A  constraint 
object  needs  to  be  added  to  the  model  for  each  informal 
constraint  identified.  The  appropriate  property  category 
must  be  selected  from:   initcond,  finalcond,  and  invariant. 

Continuing  our  previous  example,  the  entity  constraints 
specified  in  Figure  28  would  be  refined  as  in  Figure  42. 
The  constraint  that  a  child's  age  is  under  18  is  an  initial 
condition  because  the  child  could  have  a  birthday  while  they 
are  in  the  hospital.  The  invariant  specifies  that  the  'age' 
property  of  'guardian'  (which  is  inherited  from  'PERSON') 
must  have  a  value  equal  or  greater  than  21. 

CHILD 

initcond 

age  <  18 
invariant 

guardian  .  age  >=  21 

Figure  42:   RML'  Entity  Constraints 

This  layer  of  the  model  should  specify  the  following: 
a.   internal  process  constraints: 

Define  a  constraint  object  for  each  triggering 
condition,  precondition,  and  postcondition 
identified  above  and  any  other  relevant 
constraints  (e.g.,  stopping  condition); 
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b.  external  process  constraints: 

Define  a  constraint  object  for  each  data  flow 
junctor  operator  used,  each  temporal  ordering 
identified,  and  each  entity  life-cycle  stage 
constraint;  and  add  the  necessary  constraints  to 
include    a   dfd    view; 

c.  entity  constraints: 

Identify  relevant  invariants,  initial 
conditions,  final  conditions  and  any  other 
relevant    constraints    for    entities;    and 

d.  Use     the     abstraction    mechanisms    when    possible 
to    define    the    structure    of    the    constraints. 


4.9  Write  Formal  Requirements  in  RML' 
The  final  step  formalizes  all  of  the  information 
identified  in  the  previous  steps.  The  relevant  information 
has  been  identified  and  each  graphic  component  has  a  formal 
definition.  This  step  involves  simply  writing  down  the 
equivalent  RML'  definition  for  the  constructs  specified. 
The    result    is    a    formal    requirements    specification. 

This  step  is  also  done  incrementally  and  results  in 
object  definitions  for  each  non-primitive  object  (entity, 
process,  and  constraint)  included  in  the  refined  entity 
diagrams  (step  5),  the  refined  process  diagrams  (step  6), 
and  the  specified  constraints  (step  8).  An  object  is 
primitive  if  it  has  no  components,  no  property  categories, 
and    its    specification     requires     making     a     design     decision 
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(e.g.,  assigning  a  data  type).  Each  model  includes  many 
primitive  objects.  'NUMBER,'  'ADDRESS,'  and  ' PERSON_NAME ' 
are  examples  of  primitive  objects  used  in  Figure  7. 

The  formal  requirements  specification  is  written  in 
RML' .  The  information  contained  in  the  diagrams  can  be 
easily  transformed  into  an  equivalent  RML'  model  by  applying 
the  RML'  definitions  of  the  graphic  constructs  to  the 
contents  of  the  model.  Since  RML'  is  formally  defined,  its 
semantics  are  based  on  a  mathematical  formalism.  Thus  each 
of  the  features  of  RML'  have  been  mapped  into  a  First-Order 
Logic  (FOL)  [Gre84].  Therefore,  a  mapping  occurs  from  the 
graphic  constructs  to  RML'  and  from  RML'  to  a  FOL. 

The  RML'  specification  is  developed  in  a  top-down 
fashion  for  each  diagram  and  is  incrementally  refined  by  the 
information  contained  in  successive  diagrams.  The  mapping 
is  straightforward  and  its  significance  is  that  it  provides 
an  alternative  way  to  view  the  model  contents.  Furthermore, 
the  resultant  RML'  specification  is  equivalent  to  a  theory 
expressed  as  a  set  of  axioms  in  a  FOL.  This  equivalence 
allows  us  to  define  a  general  notion  of  consistency  of  an 
RML'  specification:  an  RML'  model  is  consistent  if  its  FOL 
translation  is  logically  consistent. 

Thus,  one  could  theoretically  employ  theorem  provers  to 
determine  the  consistency  of  a  model.  However,  for  the  FOL 
foundations,  this  is  undecidable.  Therefore,  a  more 
practical  approach  would  be  to  develop  a  set  of  consistency 
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rules  that  correspond  to  intuitive  notions  of  consistency 
and  use  the  FOL  formalism  to  investigate  and  analyze  these 
rules  [Gre84,  p.  86]. 

Since  the  graphic  constructs  are  formally  defined,  the 
first  eight  steps  of  the  methodology  have  already  produced  a 
formal  requirements  specification.  Therefore,  this  final 
step  should  be  considered  optional  because  it  adds  no  new 
information  to  the  model.  It  does  however,  provide  an 
alternative  way  to  view  the  model.  Although  graphics 
simplify  the  creation  of  a  specification,  they  still  may  not 
be  deemed  appropriate  in  all  circumstances  for  the  final 
specification.  The  mere  fact  that  an  RML '  specification  is 
closer  in  appearance  to  the  traditional  natural  language 
specification  may  give  it  an  advantage  over  its  graphical 
counterpart . 

The  information  provided  in  steps  7  and  8  constituted 
constraints  and  was  already  incrementally  specified  in  RML'. 
Thus,  only  the  information  contained  in  the  diagrams  needs 
to  be  translated  into  RML'.  The  RML'  definitions  of  the 
graphic  constructs  are  given  below.  To  simplify  the 
translation  process,  this  information  is  presented  in  an 
algorithmic  fashion. 
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4.9.1   Translating  from  Graphics  to  RML ' 
For  each  Refined  Entity  Diagram: 
|   is  an  Entity; 


Each 


Start  at  the  top  of  the  diagram  and  go  down; 

For  each  user  defined  entity  create: 

1.   An  object  heading. 

Choose  the  appropriate  graphic  construct  below  and 
define  its  object  heading. 

ADD: 


i  . 


A  in  B  with 


ii. 


A  isa  B  with 


iii. 


A  part-of  B  with 


IV. 


A  isa  B,  C  with 
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iv. 


A  in  B,  C  with 


I A | 


2.   A  property  category  heading  for  each  applicable 
category . 

For  each  appropriate  graphic  construct  below,  add 
its  category  heading. 

ADD: 
i. 


IZaZO 


association 


11 . 


•IZaZI 


necpart 


in . 


fazo 


component 


iv. 


producer 


v . 


£ 

I A | 


consumer 


VI. 


A 

T 


modifier 
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3.   For  each  applicable  category  as  illustrated  below, 
add  a  line  for  each  property  specified. 


i. 


J*>\  vAii/e — ) 


fWQr..-  ) 


vAuue 


ii. 


ADD: 


propl : 
prop2 


PR0P1_VALUE 
PR0P2  VALUE 


-0 A_     propl:   PR0P1_VALUE 


iii. 


C^&Cug    )?r'P     D^— A—  1         P^opl:       PR0P1_VALUE 


iv«     (nJm7~~T>\ 
IZaZI 


propl:   PR0P1_VALUE 


v  . 


i 


p**opi. 


IZO 


propl:  PR0P1_VALUE 


vi. 


propl:   PR0P1_VALUE 


To  illustrate  this  translation  process,  consider  the 
diagram  shown  in  Figure  43.  Translation  of  Figure  43  into 
RML '  using  the  above  steps  yields  the  object  definition 
shown  in  Figure  44. 
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pefcsohJ 


(EWM-iftTfJt: 


(TRgftT    ) 


Figure  43:   Entity  Structure  Diagram  to  Translate 


PHYSICIAN 


PATIENT  isa  PERSON  with 
association 

ward:   HOSPITAL_WARD 
physician:   PHYSICIAN 
consulting_physician: 

producer 

register:   ADMIT 
modifier 

evaluate:   EVALUATE 

treat:   TREAT 
consumer 

release:   RELEASE 
component 

evaluated:   EVALUATED_PATIENT 

treated:   TREATED  PATIENT 


Figure  44:   Entity  Object  Translation 
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For  each  Refined  Process  Diagram: 
Each 


is  a  Process; 

Start  at  the  top  of  the  diagram  and  go  down; 

For  each  user  defined  process  define: 

1.   An  object  heading. 

Choose  the  appropriate  graphic  construct  below  and 
define  its  object  heading. 

ADD: 
i.      

A  in  B  with 


ii. 


iii. 


ZO 


A  isa  B  with 


A  part-of  B  with 


IV 


IV 


A  isa  B,  C  with 


A  in  B,  C  with 
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2.   A  property  category  heading  for  each  applicable 
category . 

For  each  appropriate  graphic  construct  below,  add 
its  category  heading. 

ADD; 

i.     

_A (3  control 


ii. 


MZaZI 


component 


iii. 


k 


input 


iv. 


£ 


output 


3.   For  each  applicable  category  as  illustrated  below, 
add  a  line  for  each  property  specified. 


i. 


■ft"  A   VAUUg  J 


ADD: 


propl : 
prop2 : 


PR0P1_VALUE 
PR0P2  VALUE 


ii. 


Pr«rl 


(yR%LU6     ) ^°l A I         propl:       PR0P1_VALUE 


propl:   PR0P1  VALUE 
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iv. 


propl:   PR0P1_VALUE 


Consider  the  process  structure  diagram  shown  in  Figure 
45.  Translation  of  Figure  45  into  RML f  using  the  above 
steps  results  in  the  object  definition  shown  in  Figure  46. 


(CH-ElK-ip 


If*™ 


PtFKttW*  ) 


Figure  45:   Process  Structure  Diagram  to  Translate 
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ADMIT  in  PROCESS_CLASS  with 

input 

person:   PERSON 

output 

patient:   PATIENT 

control 

ward:   HOSPITAL_WARD 
physician:   PHYSICIAN 
consulting_physician:   PHYSICIAN 

component 

check_id:   CHECK_ID 
assign_ward:   CHOOSE_WARD 
pretest:   PERFORM_TESTS 

Figure  46:   Process  Object  Translation 

4.9.2   RMLf  Specification 

The  RML'  specification  for  our  previous  example  is 
given  below.  The  models  created  in  the  refined  structure 
diagrams  (Figures  9-12)  together  with  the  constraints 
identified  in  Figures  32  and  39-41  were  used  to  produce  the 
specification.  The  complete  example  is  developed  in 
Appendix  C. 
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From  the  refined  entity  diagrams: 

PERSON_CLASS  in  ENTITY_METACLASS  with 
association 

aver_age:   AGE_VALUE 
cardinality:   NUMBER 

PERSON  in  PERSON_CLASS  with 
association 

address:   ADDRESS 
age:   AGE_VALUE 
insurancej:   INSURANCE_# 
necpart 

name:   PERSON_NAME 

social_security_# :   SOCIAL_SECURITY_# 

PATIENT  isa  PERSON  with 
association 

ward:   HOSPITAL_WARD 

physician:   PHYSICIAN 

consulting_physician :   PHYSICIAN 
producer 

register:   ADMIT 
modifier 

evaluate:   EVALUATE 

treat:   TREAT 
consumer 

release:   RELEASE 
component 

evaluate:   EVALUATED_PATIENT 

treat:   TREATED_PATIENT 

CHILD  isa  PERSON  with 
association 

age:   CHILD_AGE_VALUE 

guardian:   PERSON 
initcond 

age  <  18 
invariant 

guardian  .  age  >=  21 

CHILD_PATIENT  isa  CHILD,  PATIENT  with 
association 

nurse:   NURSE 

SURGICAL_PATIENT  isa  PATIENT  with 
association 

blood_type:   BLOOD_TYPE 
surgery:   SURGERYJTYPE 
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TRANSPLANT_SURGERY_PATIENT  isa  SURGICAL_PATIENT  with 
association 

donor:   PERSON 

SURGICAL_CHILD_PATIENT  isa  CHILD_PATIENT ,  SURGICAL_PATIENT 

with 
association 

therapist:   NURSE 

EVALUATED_PATIENT  part-of  PATIENT  with 
producer 

evaluate:   EVALUATE 
modifier 

examine:   EXAMINE 

test:   TEST 
association 

physician:   PHYSICIAN 

TREATED_PATIENT  part-of  PATIENT  with 
producer 

treat:   TREAT 

EXAMINED_PATIENT  part-of  EVALUATED_PATIENT  with 
producer 

examine:   EXAMINE 
association 

physician:   PHYSICIAN 

TESTED_PATIENT  part-of  EVALUATED_PATIENT  with 
producer 

test:   TEST 


Processes : 


BE_A_HOSPITAL 
input 

person : 
output 

person: 
control 
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PATIENT  in  ACTIVITY_CLASS ,  DFD  with 
PERSON 
PERSON 


PHYSICIAN 


ward:   HOSPITAL_WARD 

physician:   PHYSICIAN 

consulting_physician: 
component 

admit:   ADMIT 

evaluate:   EVALUATE 

treat:   TREAT 

release:   RELEASE 
constraint 

si:   DFD.il  =  person 

s2:   DFD.ol  =  person 

s3:   DFD.cl  =  ward 

s4:   DFD.c2  =  physician 

s5:   DFD.c3  =  consulting_physician 

s6:   DFD.boxl  =  admit 

s7:   DFD.box2  =  evaluate 

s8:   DFD.box3  -  treat 

s9:   DFD.box4  =  release 

jl: 


j2:   Conjunctive  Join 


b2 


Exclusive  Disjunctive  Join  (inl: 

in2: 
outl : 
boxl .ol ; 
b2.outl ; 
box2  .il ) 

bl .outl ; 
b2.out2; 
box4  .il ) 
box2  .ol ; 
j3.ini ; 
box3  .il ) 

box3  .ol ; 
j2.in2; 
J3.in2) 

box4  .ol ; 
ol; 

jl.in2) 
(ADMIT,  BE_A_HOSPITAL_PATIENT) 


j3:   Conjunctive  Join 


bl:   Equality  Branch 


Equality  Branch 


b3:   Equality  Branch 


dl 

:   DURING 

d2 

DURING 

d3 

DURING 

d4 

DURING 

bl 

BEFORE 

b2 

BEFORE 

b3 

,   BEFORE 

(inl 
in2 : 
outl 
(inl 
in2: 
outl 
(inl 
outl 
out2 
(inl 
outl 
out2 
(inl 
outl 
out2 
BE  A 


il; 

b3 .out2 ; 
boxl  .il ) 


(EVALUATE,  BE_A_HOSPITAL_PATIENT) 
(TREAT,  BE_A_HOSPITAL_PATIENT) 
(RELEASE,  BE_A_HOSPITAL_PATIENT) 
(ADMIT,  EVALUATE) 
(EVALUATE,  TREAT) 
(TREAT,  RELEASE) 
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ADMIT  part-of  BE_A_HOSPITAL_PATIENT  with 
input 

person:   PERSON 
output 

patient:   PATIENT 
control 

ward:   HOSPITAL_WARD 

physician:   PHYSICIAN 

consulting_physician:   PHYSICIAN 
component 

check_id:   CHECK_ID 

assign_ward:   CHOOSE_WARD 

pretest:   PERFORM_TESTS 
actcond 

arrival:   ARRIVAL(person) 
precondition 

already_in?:   not   A_PATIENT(person) 

available_room?:  ROOM_LEFT 
postcondition 

admitted?:  IN_HOSPITAL( person) 

ADMIT_CHILD_PATIENT  isa  ADMIT  with 
input 

person:   CHILD 
output 

patient:   CHILD_PATIENT 
control 

nurse:   NURSE 
component 

find_nurse:   FIND_NURSE 

ADMIT_SURGICAL_PATIENT  isa  ADMIT  with 
output 

patient:   SURGICAL_PATIENT 
control 

blood_type:   BLOOD_TYPE 

surgery:   SURGERY_TYPE 
component 

blood_typing:   BLOOD_TYPING 

ADMIT_SURGICAL_CHILD_PATIENT  isa  ADMIT_CHILD_PATIENT, 

ADMIT_SURGICAL_PATIENT  with 
output 

patient:   SURGICAL_CHILD_PATIENT 
control 

therapist:   NURSE 
component 

get_permission:   OBTAIN_PERMISSION 
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ADMIT_TRANSPLANT_SURGICAL_PATIENT  isa  ADMIT_SURGICAL_PATIENT 

with 
output 

patient:   TRANSPLANT_SURGERY_PATIENT 
control 

donor:   PERSON 

CHECK_ID  part-of  ADMIT  with 
input 

person:   PERSON 
output 

identified:   IDENTIFIED_PATIENT 

CHOOSE_WARD  part-of  ADMIT  with 
input 

identified:   IDENTIFIED_PATIENT 
output 

assigned:   ASSIGNED_PATIENT 
control 

ward:   HOSPITAL_WARD 

PERFORM_TESTS  part-of  ADMIT  with 
input 

assigned:   ASSIGNED_PATIENT 
output 

admitted:   ADMITTED_PATIENT 
control 

physician:   PHYSICIAN 

consulting_physician:   PHYSICIAN 

Constraints : 

A_PATIENT?  in  ASSERTION_CLASS  with 
argument 

person:   PERSON 
part 

patient?:   IN  (person,  PATIENT) 

ROOM_LEFT  in  ASSERTION_CLASS  with 
constraint 

room?:   PATIENT .cardinality  <  PATIENT_MAX 

IN_HOSPITAL  in  ASSERTION_CLASS  with 

argument 

person:   PERSON 

part 

patient?:   A_PATIENT? ( person) 
present? :   PHYSICALLY_PRESENT(person) 
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4.10      Developing    a    Consistent    Model 

Closely  following  the  steps  of  the  methodology  will 
result  in  a  thorough,  formal,  requirements  specification, 
although  not  necessarily  a  consistent  one.  Developing  a 
consistent  model  requires  analyzing  the  model  itself  to 
eliminate  errors  created  during  the  requirements  phase. 
This  section  presents  suggestions  for  analyzing  the 
consistency    of    a    developing    model. 

The  most  important  factor  in  developing  a  consistent 
model  is  understanding  the  semantics  of  what  is  being 
specified.  The  refined  structure  diagrams  contain  a 
tremendous  amount  of  information,  all  of  which  needs  to  be 
verified  for  accuracy.  This  verification  should  be  both 
within    each    diagram   and    between    related    diagrams. 

Consider  the  refined  generalization  structure  diagrams 
(Figures  9  and  11).  These  diagrams  are  modeling  type/ 
subtype  object  specializations.  Recall  that  subtypes 
inherit  all  definitional  properties  of  their 
generalizations.  Subtypes  may  specify  additional  properties 
or  specialize  the  property  values  of  their  inherited 
properties.  For  example,  'PERSON'  has  the  associated 
properties  'address,'  'age,'  and  '  insurance_# .  '  Since 
'PATIENT'  is  a  subclass  of  'PERSON,'  it  inherits  these 
properties.  Additional  properties  are  also  specified  (e.g., 
'ward').  'CHILD'  also  inherits  the  definitional  properties 
of     'PERSON.'        Note    that     'CHILD'     refines    the     'age'     property 
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by    specifying    the    property     value     '  CHILD_AGE_VALUE.  '        Since 
'CHILD    isa    PERSON*     it    must    also    be    the    case    that     'CHILD_ 
AGE_VALUE    isa    AGE_VALUE.' 

This  specialization  can  be  seen  further  in  the  'is-a' 
related  processes  depicted  in  Figure  11.  'ADMIT'  has  the 
input  property  'person'  with  a  property  value  of  'PERSON,' 
and  the  output  property  'patient'  with  a  property  value  of 
PATIENT.'  The  specializations  inherit  these  properties, 
and  may  or  may  not  refine  the  property  values.  For  example, 
'ADMIT_CHILD_PATIENT'  refines  the  value  of  the  'person' 
input  property  to  'CHILD'  and  refines  the  value  of  the 
'patient'  output  property  to  '  CHILD_PATIENT.  *  It  must  be 
the  case  that  'CHILD  isa  PERSON'  and  '  CHILD_PATIENT  isa 
PATIENT.'  This  should  be  verified  on  the  entity 
generalization    structure    diagram. 

Continuing  down  the  hierarchy  of  Figure  11, 
'ADMIT_SURGICAL_CHILD_PATIENT  isa  ADMIT_CHILD_PATIENT '  and 
therefore  it  inherits  the  specialized  property  values. 
Note,  that  since  no  input  property  value  is  specified,  its 
'person'  property  has  the  value  'CHILD.'  The  output  is 
refined,  and  thus  its  'patient'  property  has  the  value 
'SURGICAL_CHILD_PATIENT.  '  Therefore,  it  must  be  the  case 
that  'SURGICAL_CHILD_PATIENT  isa  CHILD_PATIENT. '  This  type 
of  verification  needs  to  be  made  for  all  property 
specializations    of    'is-a'     related    objects. 

The     information     contained    in    the    refined    aggregation 
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diagrams  (Figures  10  and  12)  needs  to  be  compared  with  the 
generalization  diagrams.  Consider  the  'ADMIT'  process  of 
Figures  11  and  12.  It  has  the  associated  properties  'ward,' 
'physician,'  and  ' consulting_physician , '  and  it  produces  a 
'PATIENT'  as  output.  These  associated  properties  are 
actually  control  items  on  the  corresponding  dfd.  They 
effect  the  processing  of  'ADMIT,'  which  means  they  must  also 
be  associated  with  its  output  'PATIENT.'  This  relationship 
is  shown  on  Figures  9  and  10.  'PATIENT'  has  these  control 
items  as  associated  properties. 

Examining  'PATIENT'  further,  note  that  'ADMIT'  is  its 
producer.  This  verifies  that  'PATIENT'  is  the  output  of 
'ADMIT.'  'EVALUATE'  AND  'TREAT'  are  modifiers  of  'PATIENT.' 
Modifiers  alter  the  attributes  of  an  entity,  and  the 
attributes  correspond  to  different  life-cycle  stages.  The 
different  life-cycle  stages  are  components  of  the  entity. 
Figure  9  shows  that  'PATIENT'  has  components  '  EVALUATED_ 
PATIENT'  and  ' TREATED_PATIENT. '  This  relationship  is  also 
verified  on  Figure  10  which  shows  ' EVALUATED_PATIENT  part-of 
PATIENT'  and  'TREATED_PATIENT  part-of  PATIENT.' 

The  aggregation  structure  diagrams  (Figures  10  and  12) 
represent  the  semantics  of  the  aggregate/component 
relationship.  Even  though  properties  of  the  aggregate  are 
not  inherited  by  a  component,  there  is  a  subtle  relationship 
that  must  be  acknowledged.  Properties  of  a  component  must 
be  related  to  the  properties  of  the  aggregate.   That  is,  a 
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property     of     a     component     must     either     reference,      be     a 
component     of,      or     be     a     subtype     of     a     property     of     the 
aggregate.      This    corresponds    to    data    leveling    that    occurs    in 
decompositions    of    dfds. 

Consider  the  'ADMIT'  process  of  Figure  12.  The 
semantics  of  the  aggregate/component  relationship  imply  that 
the  components  occur  during  the  aggregate.  Thus,  'ADMIT' 
occurs  only  when  'CHECK_ID,*  '  C H 00 S E_W A R D ,  '  and 
'PERFORM_TESTS'  have  occurred.  Therefore,  all  properties  of 
'ADMIT'  should  be  referenced  by  some  component.  (Note,  a 
component  or  subtype  of  a  property  might  be  referenced 
instead  of  the  entire  property.)  '  CH00SE_WARD '  has  the 
'ward'  property  and  ' PERFORM_TESTS '  has  the  'physician*  and 
' consul ting_physician'    properties. 

This  obligatory  referencing  of  an  aggregate's 
properties  by  a  component  in  the  aggregation  structure 
diagrams  is  directly  opposed  to  the  property  specialization 
that  occurs  in  the  generalization  structure  diagrams.  In 
generalization  diagrams  additional  properties  are  supplied 
to  introduce  detail  for  special  cases.  Care  should  be  taken 
not    to    confuse    the    semantics    of    the    two    opposing    views. 

This  chapter  presented  the  requirements  methodology. 
The  nine  steps  of  the  methodology  were  discussed,  and  an 
example  was  developed  throughout  the  chapter.  The  next 
chapter    provides    a    summary    of    the    research. 


CHAPTER    5 
SUMMARY 


This  dissertation  develops  a  methodological  approach 
for  requirements  analysis  and  specification  that  utilizes 
conceptual  modeling  to  incrementally  develop  and  formally 
specify  requirements.  The  methodology  provides  a  graphical 
formalism  for  specification  within  an  object-oriented 
framework.  The  formal  requirements  specification  is 
expressed  in  RML'.  RML'  is  a  requirements  modeling  language 
based  on  RML  that  is  defined  in  the  dissertation  to 
simplify  the  syntax  and  extend  the  underlying  semantics  of 
RML. 

The  basic  assumption  underlying  the  methodology  is  that 
humans  use  abstraction  mechanisms  (classification, 
generalization,  and  aggregation)  for  understanding  complex 
systems.  Therefore,  those  same  abstractions  should  be  used 
for  organizing  and  identifying  the  requirements  of  a  system. 
Furthermore,  applying  those  abstractions  within  a  framework 
that  emphasizes  information  hiding,  data  abstraction,  and 
inheritance  results  in  requirements  that  are  reliable, 
modifiable,    and    easy    to    understand. 

The  methodology  applies  an  object-oriented  framework  to 
the     conceptual     modeling     of     requirements.        The    modeling 
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strategy    integrates    conceptual    modeling     concepts     such    as 
hierarchical    structures,     the    role    of    the    environment,    and    a 
temporal    framework    with    a    dfd    based    functional    analysis    for 
a   truly    unified    approach    to    requirements. 

This  dissertation  addresses  the  problem  of  requirements 
modeling  from  a  knowledge  representation  perspective.  One 
of  the  major  tasks  addressed  by  this  research  was  to 
discover  what  types  of  knowledge  should  be  expressed  during 
the  various  stages  of  requirements  acquisition  and  to 
determine  how  to  best  represent  that  knowledge.  The 
methodology  incorporates  this  information  and  guides  the 
analyst    through    the    entire    requirements    modeling    task. 


5.1      Evaluation 

This  dissertation  presented  a  novel  approach  to 
requirements  modeling  that  combines  the  best  features  of 
many  existing  techniques  into  a  unified  framework.  Chapter 
two  discussed  work  related  to  our  research.  Since  our 
framework  had  not  yet  been  presented  (it  was  discussed  in 
Chapter  three),  a  detailed  comparison  of  our  approach  to 
other  existing  approaches  has  not  been  made.  This  section 
presents    that    comparison. 

The  characteristics  being  considered  include  the  use  of 
data  abstraction,  information  hiding,  abstraction 
mechanisms,  and  inheritance;  whether  the  methods  are  formal 
or    graphical;    the    introduction    of    design    concepts    during    the 
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requirements     phase;     and     addressing     both     requirements 
analysis    and    specification. 

The  requirements  methods  being  compared  with  our 
methodology  are  functional  decomposition,  conceptual 
modeling,  and  object-oriented  analysis.  We  refer  to  our 
approach  as  Requirements  Analysis  and  Specification 
Methodology    (RASM). 

REQUIREMENTS   METHODS 

Functional  Conceptual      Object-        RASM 

Decomposition      Modeling  Oriented 

FEATURES 

Data  Abstraction  x         x 

Information  x         x 

Hiding 

Abstraction  x  x         x 

Mechanisms 

Inheritance  x  x         x 

Formal  x 

Graphical  x  x 

Does  Not  Use  x  x  x 

Design 
Concepts 

Analysis  and  x 

Specification 

5.2   Limitations  of  the  Study 

The  methodology  was  designed  with  the  conceptual 

modeling  language  RML  in  mind.   As  the  research  progressed, 

specific  limitations  of  RML  led  to  the  development  of  RML' . 

Deficiencies  in  the  underlying  framework  were  remedied  as 
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they  were  encountered.    The  result  is  a  very  close 
relationship  between  the  requirements  methodology  and  the 
underlying  formal  requirements  specification  language.   This 
relationship  may  be  viewed  as  a  limitation. 

Another  limitation  has  to  do  with  one  of  the  analysis 
techniques  utilized  in  the  methodology.  The  dfd-based 
analysis  consists  of  a  simplified  dfd  representation.  The 
limitation  is  that  it  does  not  allow  for  the  representation 
of  control  processes.  This  makes  modeling  real-time  systems 
difficult.  However,  the  temporal  constraints  specified  in 
steps  7  and  8  provide  assistance  in  this  area. 


5.3   Directions  for  Future  Research 
The  focus  for  future  research  involves  developing 
various  tools  to  assist  in  the  development  of  requirements 
modeling  based  on  the  methodology.   These  include: 

1.  A  graphical  tool  to  assist  in  creating  the  models. 

2.  An  implementation  of  RML1  that  would  yield  an 
executable  specification.  This  would  enable  the  analyst  to 
simulate  the  system  and  eliminate  some  of  the  problems 
resulting  from  not  getting  the  requirements  right. 

3.  A  knowledge-based  system  designed  to  check  the 
consistency  of  the  developing  model.  It  would  minimally  be 
knowledgeable  about  the  syntax  of  the  graphic  constructs. 

4.  A  k n o w 1 e d g e - b a s e d  system  to  automate  the 
transformation  from  graphics  to  RML'.  This  would  provide  a 
textual  specification  in  addition  to  the  graphical  one. 
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5.  A  CASE-type  knowledge-based  development  tool  that 
incorporates  all  of  the  above  into  a  development  environment 
that  addresses  the  entire  software  development  life-cycle. 
In  addition  to  all  of  the  above  types  of  knowledge,  it  would 
also  include  knowledge  about  the  software  development  task 
itself,  and  other  tools  such  as  data  bases  for  storing  the 
models,  and  record-keeping  facilities  for  documenting  the 
development  and  recording  changes. 


APPENDIX  A 
RML'  SYNTAX 


The  following  notation  is  used  to  define  the  language: 

Meta-symbols  (unless  quoted):   <>:={}{} 

Symbols  underlined,  in  boldface,  and  all-caps  are  terminals 

Symbols  consisting  of  a  string  in  angle  brackets  (<  >)  are 
nonterminals 

[<symbol>]  signifies  zero  or  one  occurence  of  <symbol> 

{<symbol>}  signifies  zero  or  more  occurrences  of  <symbol> 

{<symbol>}+  signifies  one  or  more  occurrences  of  <symbol> 

An  RML'  Requirements  Model  consists  of: 

<reqs-model>  :=  { ob ject-def n>}+ 

<object-defn>   :=    <subject>  <class-info>  with 

{<definitional-properties>}+ 

<class-info>  :=   in  <classifier> 

isa  <generalization> 
part-of  <aggregate> 

<generalization>  :=   (superclass)  { , (superclass)) 

<subject>  :=   <user-made-ob ject> 

<classifier>  :=   <object>  {,<object>} 

(aggregate)  :=   (object) 

(superclass)  :=   (user-made-object) 

(definitional-properties)  := 

(property-category)  {(definitional-property)} 
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<def initional-property>  := 

<attribute>  :  <property-value> 

<property-category>  := 

<entity-pcat>    <process-pcat> 
<constraint-pcat> 

<entity-pcat>  :=   necpart    association    component 
invariant    initcond    f inalcond 
producer    consumer    modifier 
constraint 

<process-pcat>  :=   input    output    control    precond 

postcond      a  c  t  c  o  n  d      stopcond 
component    constraint 

<constraint-pcat>  :=   argument    part    suf f cond    def n 
constraint 

<property-value>  :=  <object>  [ (<bindings>) ] 

<bindings>  :=   <fact>  (,<fact>) 

<object>  :=  <user-def ined-ob ject>    <built-in-ob ject> 

<built-in-object>  :=  CLASS  |  ENTITY_CLASS 

PROCESS_CLASS    CONSTRAINT_CLASS 
ENTITY_METACLASS    PROCESS_METACLASS 
CONSTRAINT_METACLASS  |  nothing 

<user-def ined-ob ject>  :=   <user-made-ob ject> 
<constraint> 

<user-made-ob ject>  :=  <upper-case-identif ier> 

<fact>  :=   <attribute>  :  <attr-expr> 
<attr-expr>  .  <attr-expr> 
<attr-expr> 

<attr-expr>  :=   <object>    <attribute> 
<built-in-term> 

<attribute>  :=   <user-def ined-attr> 

<user-def ined-attr>  :=   <lower-case-identif ier> 

<built_in_term>  :=  RANGE( <bindings>)    PVAL(<bindings>) 

START(<bindings>)    END( <bindings>) 
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(constraint)  :=   <predicate>  ((bindings)) 

<bindings>  <built-in-pred>  <bindings> 
FORALL  <var>  in  <object>  <constraint> 
EXISTS   <var>   in   (object)   SUCHTHAT 
(constraint) 
NOT  (constraint) 
(constraint)  (connective)  (constraint) 

(connective)  :=  AND  |  OR  |  IMPLIES  |  IFF 

(predicate)  :=  (user_def ined_ob ject) 

(built_in_pred>  :=  IN  |  ISA  |  PARTOF  |  =  |  (  |  >  |  (= 

I  >=  . 


(var)  :=  (lower_case_variable>  { , (lower_case_variable> } 


APPENDIX  B 
SEMANTICS  OF  'IS-A'  AND  'IN' 


Semantic  distinctions  have  been  made  that  clarify  the 
intent  of  the  use  of  'is-a'  and  'in.'  Consider  the 
following  examples: 

Let  PERSON_CLASS  be  a  metaclass  with  property: 

cardinality 
Let  PERSON  be  a  class  with  property: 

name 
Let  STUDENT  be  a  class  with  property: 

grade_level 
Let  GRAD_STUDENT  be  a  class  with  property: 

degree 

Given  :  A  isa  B 

and  B  isa  C 

Does  that  imply  :    A  isa  C  ? 

Let  A  =  GRAD_STUDENT,  B  =  STUDENT,  and  C  =  PERSON.   By 

the  'is-a'  constraints,  STUDENT  has  properties  'name'  and 

' grade_level .  '    Similarly,  GRAD_STUDENT  has  properties 
'name,'  '  grade_level ,  '  and  'degree.'    Furthermore,  since 

every  instance  of  GRAD_STUDENT  is  an  instance  of  STUDENT  and 

every  instance  of  STUDENT  is  an  instance  of  PERSON,  it 
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follows  that  every  instance  of  GRAD_STUDENT  is  an  instance 
of  PERSON,  and  GRAD_STUDENT  isa  PERSON. 

Result:  'is-a'  is  a  transitive  relationship  and  as  such, 
all  definitional  properties  should  be  inherited  accordingly. 

Given  :  A  in  B 

and  B  in  C 

Does  that  imply  :    A  in  C  ? 

Intuitively,  the  above  feels  right.  However,  upon 
closer  examination  it  is  not.  Assume  B  is  level  n.  A  in  B 
means  A  is  level  n-1.  B  in  C  means  C  is  level  n+1.  Thus,  A 
in  C  implies  A  is  one  level  less  than  C,  or  n.  But  it  has 
already  been  established  that  A  is  level  n-1.  Therefore,  A 
in  B,  and  B  in  C,  does  NOT  imply  A  in  C. 

Result:  'in'  is  not  a  transitive  relationship  and  factual 
properties  may  be  induced  only  for  an  instance  of  a  class  or 
metaclass. 

Given  :  C  isa  A 

and  A  in  B 

Does  that  imply  :    C  in  B  ? 

Let  A  =  PERSON,  B  =  PERSON_CLASS ,  and  C  =  STUDENT.  A 
in  B  means  A  has  an  induced  factual  property  'cardinality.' 
By  the  intentional  'is-a'  constraint,  C  isa  A  means  C 
inherits  the  definitional  properties  of  A.  So  C  has  'name' 
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and  '  grade_level '  properties.  Assuming  the  implication  is 
valid,  C  in  B  means  that  C  has  the  additional  induced 
factual  property  'cardinality.'  The  question  becomes, 
should  ' is-a1  allow  for  the  factual  properties  as  well  as 
the  definitional  properties  to  be  inherited? 

According  to  the  extensional  'is-a'  constraint,  C  isa  A 
implies  that  if  you  have  a  C,  you  have  an  A  (e.g.,  every 
STUDENT  is  also  a  PERSON).  The  premise  states  that  A  is  an 
instance  of  B  (e.g.,  classes  of  PERSONS  have  been  collected 
to  form  a  metaclass  to  emphasize  their  'cardinality' 
property).  Therefore,  since  every  C  is  an  A,  and  A  is  an 
instance  of  B,  it  follows  that  C  is  an  instance  of  B  (e.g., 
the  class  of  STUDENTS  are  in  PERSON_CLASS  and  have  a 
'cardinality'  property). 

Result:   If  C  isa  A  and  A  in  B,  then  C  in  B. 

Given  :  A  in  B 

and  A  isa  C 

Does  that  imply  :    C  in  B  ? 

This  is  similar  to  the  case  above,  but  this  time  we  are 
given  that  STUDENT  in  PERSON_CLASS ,  and  STUDENT  isa  PERSON. 
Should  PERSON  also  be  an  instance  of  PERSON_CLASS?  Yes.  We 
need  a  stronger  statement  that  can  handle  all  of  these 
cases . 

The  previous  examples  have  shown  the  inadequacy  of  the 
RML  semantics  regarding  the  use  of  'in'  and  'isa.'   To 
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remedy  this  situation,  the  following  semantic  distinctions 
have  been  incorporated  in  RML' : 

Definition;   If  A  isa  B  and  B  isa  C  then  A  isa  C 
and  A,  B,  and  C  are  'is-a  related.1 


Property ;  If  A  is  an  instance  of  B,  then  all 
objects  'is-a  related'  to  A  are  also  instances  of 
B  and  have  induced  factual  properties 
corresponding  to  each  definitional  property  of  B. 


APPENDIX  C 
THE  COMPLETE  HOSPITAL/PATIENT  MODEL 

The  example  that  was  partially  developed  throughout  the 
text  is  presented  here  in  its  entirety.  This  example  was 
originally  presented  by  Greenspan  [Gre84]  and  involves  the 
development  of  a  medical  information  system.  Greenspan  only 
partially  developed  the  model  which  he  presented  in  RML. 
In  contrast,  our  example  is  used  to  demonstrate  a 
comprehensive  approach  to  requirements  modeling,  and 
consequently,  illustrates  the  model  in  all  phases  of 
development . 

Since  in  actual  modeling  practice  the  layers  of  a 
diagram  can  be  added  onto  the  same  diagram,  we  only  need  to 
show  the  refined  diagrams  for  each  model.  The  optional  RML' 
model  is  presented  after  the  diagrams  for  completion. 

The  diagrams  are  presented  in  the  typical  top-down 
fashion.  The  lowest  level  objects  that  are  not  decomposed 
any  further  should  be  considered  primitive. 

The  RML1  model  is  presented  with  entities,  processes, 
and  constraints  being  collected  together.  Within  each 
object  category,  a  top-down  presentation  is  used. 
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Figure    54:    Process    Generalization    —    EVALUATE 
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The  Formal  RML'  Model: 


Entities: 


PERS0N_CLASS  in  ENTITY_METACLASS  with 
association 

aver_age:   AGE_VALUE 
cardinality:   NUMBER 

PERSON  in  PERS0N_CLASS  with 
association 

address:   ADDRESS 

age:   AGE_VALUE 

insurancej:   INSURANCE_# 
necpart 

name:   PERSON_NAME 

social_security_# :   SOCIAL_SECURITY_# 

PATIENT  isa  PERSON  with 
association 

ward:   HOSPITAL_WARD 

physician:   PHYSICIAN 

consulting_physician :   PHYSICIAN 
producer 

register:   ADMIT 
modifier 

evaluate:   EVALUATE 

treat:   TREAT 
consumer 

release:   RELEASE 
component 

evaluated:   EVALUATED_PATIENT 

treated:   TREATED_PATIENT 

admitted:   ADMITTED_PATIENT 

EVALUATED_PATIENT  part-of  PATIENT  with 
producer 

assess:   ASSESS 
modifier 

examine:   EXAMINE 

test:   TEST 
component 

examined:   EXAMINED_PATIENT 

tested:   TESTED  PATIENT 
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TREATED_PATIENT  part-of  PATIENT  with 
producer 

treat:   TREAT 

ADMITTED_PATIENT  part-of  PATIENT  with 
producer 

pretest:   PERFORMJTESTS 
modifier 

check_id:   CHECK_ID 

assign_ward:   CHOOSE_WARD 
component 

identified:   IDENTIFIED_PATIENT 

assigned:   ASSIGNED_PATIENT 

pretested:   PRETESTED_PATIENT 

EXAMINED_PATIENT  part-of  EVALUATED_PATIENT  with 
producer 

examine:   EXAMINE 
association 

physician:   PHYSICIAN 

TESTED_PATIENT  part-of  EVALUATED_PATIENT  with 
producer 

test:   TEST 

IDENTIFIED_PATIENT  part-of  ADMITTED_PATIENT  with 
producer 

check_id:   CHECK_ID 

ASSIGNED_PATIENT  part-of  ADMITTED_PATIENT  with 
producer 

assign_ward:   CHOOSE_WARD 

PRETESTED_PATIENT  part-of  ADMITTED_PATIENT  with 

producer 

take_temp:   TAKE_TEMP 

component 

analyzed:   ANALYZED_PATIENT 
blood_counted :   BLOOD_COUNTED_PATIENT 
blood_pressured :   BLOOD_PRESSURED_PATIENT 

ANALYZED_PATIENT  part-of  PRETESTED_PATIENT  with 
producer 

urinalysis:   URINALYSIS 

BLOOD_COUNTED_PATIENT  part-of  PRETESTED_PATIENT  with 
producer 

blood_count:   TAKE_BL00D_C0UNT 

BLOOD_PRESSURED_PATIENT  part-of  PRETESTED_PATIENT  with 
producer 

blood_pressure :   TAKE_BLOOD_PRESSURE 
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CHILD  isa  PERSON  with 
association 

age:   CHILD_AGE_VALUE 

guardian:   PERSON 
initcond 

age  <  18 
invariant 

guardian  .  age  >■  21 

CHILD_PATIENT  isa  CHILD,  PATIENT  with 
association 

nurse:   NURSE 

SURGICAL_PATIENT  isa  PATIENT  with 
association 

blood_type:   BLOODJTYPE 
surgery:   SURGERY 

TRANSPLANT_SURGERY_PATIENT  isa  SURGICAL_PATIENT  with 
association 

donor:   PERSON 

SURGICAL_CHILD_PATIENT  isa  CHILD_PATIENT ,  SURGICAL_PATIENT 

with 
association 

therapist:   NURSE 
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Processes ; 

BE_A_HOSPITAL 

input 

pers 

output 
pers 

control 
ward 
phys 
cons 

componen 
admi 
eval 
trea 
rele 

constrai 


_PATIENT  in  PROCESS_CLASS ,  DFD  with 
on:   PERSON 
on:   PERSON 


:   HOSPITAL_WARD 

ician:   PHYSICIAN 

ulting_physician : 

t 

t:   ADMIT 

uate:   EVALUATE 

t:   TREAT 

ase:   RELEASE 

nt 


PHYSICIAN 


si:  DFD.il  =  person 

s2:  DFD.ol  =  person 

s3:  DFD.cl  =  ward 

s4:  DFD.c2  =  physician 

s5:  DFD.c3  ■  consulting_physician 

s6:  DFD.boxl  =  admit 

s7:  DFD.box2  =  evaluate 

s8:  DFD.box3  =  treat 

s9:  DFD.box4  =  release 

jl:  Exclusive  Disjunctive 


Join 


j2:   Conjunctive  Join  (inl 

in2: 

outl 

j3:   Conjunctive  Join  (inl 

in2: 
outl 
bl:   Equality  Branch  (inl 

outl 

out2 

b2:   Equality  Branch  (inl 

outl 

out2 

b3:   Equality  Branch  (inl 

outl 
out2 
(ADMIT,  BE_A_HOSPITAL_PATIENT) 
(EVALUATE,  BE_A_HOSPITAL_PATIENT) 
(TREAT,  BE_A_HOSPITAL_PATIENT) 
(RELEASE,  BE_A_HOSPITAL_PATIENT) 
(ADMIT,  EVALUATE) 
(EVALUATE,  TREAT) 
(TREAT,  RELEASE) 


(inl: 
in2: 
outl : 
boxl  .ol ; 
b2.outl ; 
box2  .il ) 

bl .outl ; 
b2.out2; 
box4  .il ) 
box2  .ol ; 
j3.ini ; 
box3  .il ) 

box3  .ol ; 
j2.in2; 
j3.in2) 

box4  .ol ; 
ol; 
jl.in2) 


il; 
b3.out2 ; 
boxl  .il ) 


dl 

DURING 

d2 

DURING 

d3 

DURING 

d4 

DURING 

bl 

:   BEFORE 

b2 

BEFORE 

b3 

:   BEFORE 
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ADMIT  part-of  BE_A_HOSPITAL_PATIENT  with 

input 

person:   PERSON 

output 

patient:   PATIENT 

control 

ward:   HOSPITAL_WARD 
physician:   PHYSICIAN 
consulting_physician :   PHYSICIAN 

actcond 

arrival:   ARRIVAL( person) 

precondition 

already_in?:   not   A_PATIENT( person) 
available_room?:  ROOM_LEFT 

postcondition 

admitted?:  IN_HOSPITAL( person) 

component 

check_id:   CHECK_ID 
assign_ward:   CHOOSE_WARD 
pretest:   PERFORM_TESTS 

constraint 

si:   DFD.il  =  person 

s2:   DFD.ol  =  patient 

s3:   DFD.cl  =  ward 

s4 :   DFD.c2  =  physician 

s5:   DFD.c3  =  consulting_physician 

s6:   DFD.boxl  =  check_id 

s7:   DFD.box2  =  assign_ward 

s8:   DFD.box3  =  pretest 

dl:   DURING  (CHECK_ID,  ADMIT) 

d2:   DURING  (CHOOSE_WARD ,  ADMIT) 

d3:   DURING  (PERFORM_TESTS ,  ADMIT) 

ADMIT_CHILD_PATIENT  isa  ADMIT  with 
input 

person:   CHILD 
output 

patient:   CHILD_PATIENT 
control 

nurse:   NURSE 
component 

find_nurse:   FIND_NURSE 
constraint 

si:   DFD.c4  =  nurse 

s2:   DFD.box4  =  find  nurse 
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ADMIT_SURGICAL_PATIENT  isa  ADMIT  with 
output 

patient:   SURGICAL_PATIENT 
control 

blood_type:   BL00D_TYPE 

surgery:   SURGERY_TYPE 
component 

blood_typing:   BLOOD_TYPING 
constraint 

si:   DFD.c4  =  blood_type 

s2:   DFD.c5  ■  surgery 

s3:   DFD.box4  ■  blood_typing 

ADMIT_SURGICAL_CHILD_PATIENT  isa  ADMIT_CHILD_PATIENT, 

ADMIT_SURGICAL_PATIENT  with 
output 

patient:   SURGICAL_CHILD_PATIENT 
control 

therapist:   NURSE 
component 

get_permission:   OBTAIN_PERMISSION 
constraint 

si:   DFD.c4  =  therapist 

s2:   DFD.box4  =  get_permission 

ADMIT_TRANSPLANT_SURGICAL_PATIENT  isa  ADMIT_SURGICAL_PATIENT 

with 
output 

patient :   TRANSPLANT_SURGERY_PATIENT 
control 

donor:   PERSON 
constraint 

si:   DFD.c4  -  donor 
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EVALUATE  part-of  BE_A_HOSPITAL_PATIENT  with 
input 

patient:   PATIENT 
output 

evaluated:   EVALUATED_PATIENT 
control 

physician:   PHYSICIAN 
actcond 

arrival:   ARRIVAL(patient ) 
precondition 

already_evaluated? :   not  EVALUATED? ( patient ) 
postcondition 

evaluation_complete?:  EVALUATED? (patient ) 
component 

examine:   EXAMINE 

test:   TEST 

assess:   ASSESS 
constraint 

si:   DFD.il  ■  patient 

s2:   DFD.ol  =  evaluated 

s3:   DFD.cl  =  physician 

s4:   DFD.c2  =  evaluated 

s5:   DFD.boxl  =  examine 

s6:   DFD.box2  =  test 

s7:   DFD.box3  ■  assess 

dl:   DURING  (EXAMINE,  EVALUATE) 

d2:   DURING  (TEST,  EVALUATE) 

d4:   DURING  (ASSESS,  EVALUATE) 

bl:   BEFORE  (EXAMINE,  TEST) 

b2:   BEFORE  (TEST,  ASSESS) 

EVALUATE_CHILD_PATIENT  isa  EVALUATE  with 
input 

patient:   CHILD_PATIENT 
control 

nurse:   NURSE 
constraint 

si:   DFD.c4  =  nurse 

EVALUATE_SURGICAL_PATIENT  isa  EVALUATE  with 
input 

patient:   SURGICAL_PATIENT 
control 

surgery:   SURGERY_TYPE 
constraint 

si:   DFD.c4  =  surgery 
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EVALUATE_SURGICAL_CHILD_PATIENT  isa  EVALUATE_CHILD_PATIENT, 

EVALUATE_SURGICAL_PATIENT  with 
input 

patient:   SURGICAL_CHILD_PATIENT 
control 

therapist:   NURSE 
constraint 

si:   DFD.c4  =  therapist 

EVALUATE_TRANSPLANT_SURGICAL_PATIENT  isa 

EVALUATE_SURGICAL_PATIENT  with 
input 

patient :   TRANSPLANT_SURGERY_PATIENT 
control 

donor:   PERSON 
constraint 

si:   DFD.c4  =  donor 

TREAT  part-of  BE_A_HOSPITAL_PATIENT  with 
input 

evaluated:   EVALUATED_PATIENT 
output 

treated:   TREATED_PATIENT 
actcond 

arrival:   ARRIVAL( evaluated) 
precondition 

already_treated? :   not  TREATED? (evaluated) 
postcondition 

treatment_complete? :  TREATED? ( evaluated) 
constraint 

si:   DFD.il  =  evaluated 

s2:   DFD.ol  =  treated 

RELEASE  part-of  BE_A_HOSPITAL_PATIENT  with 
input 

patient:   PATIENT 
output 

person:   PERSON 
actcond 

arrival:   ARRIVAL(patient) 
constraint 

si:   DFD.il  =  patient 

s2:   DFD.ol  ■  person 
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EXAMINE  part-of  EVALUATE  with 
input 

patient:   PATIENT 
output 

examined:   EXAMINED_PATIENT 
control 

physician:   PHYSICIAN 
actcond 

arrival:   ARRIVAL( patient ) 
precondition 

already_examined?:   not  EXAMINED? ( patient) 
postcondition 

examination_complete? :  EXAMINED? (patient ) 
constraint 

si:   DFD.il  =  patient 

s2:   DFD.ol  -  evaluated 

s3:   DFD.cl  =  physician 

TEST  part-of  EVALUATE  with 
input 

examined:   EXAMINED_PATIENT 
output 

tested:   TESTED_PATIENT 
actcond 

arrival:   ARRIVAL( examined) 
precondition 

already_tested?:   not  TESTED? (examined) 
postcondition 

testing_complete? :  TESTED? ( examined) 
constraint 

si:   DFD.il  =  examined 

s2:   DFD.ol  =  tested 

ASSESS  part-of  EVALUATE  with 
input 

tested:   TESTED_PATIENT 
output 

evaluated:   EVALUATED_PATIENT 
control 

physician:   PHYSICIAN 
actcond 

arrival:   ARRIVAL( tested) 
precondition 

already_assessed?:   not  ASSESSED? (tested) 
postcondition 

assessment_complete? :  ASSESSED? (tested) 
constraint 

si:   DFD.il  -  tested 

s2:   DFD.ol  =  evaluated 

s3:   DFD.cl  =  physician 
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CHECK_ID  part-of  ADMIT  with 
input 

person:   PERSON 
output 

identified:   IDENTIFIED_PATIENT 
actcond 

arrival:   ARRIVAL(person) 
precondition 

already_ided? :   not  IDED? ( person) 
postcondition 

id_complete? :  IDED? ( person) 
constraint 

si:   DFD.il  =  person 

s2:   DFD.ol  =  identified 

CHOOSE_WARD  part-of  ADMIT  with 
input 

identified:   IDENTIFIED_PATIENT 
output 

assigned:   ASSIGNED_PATIENT 
control 

ward:   HOSPITAL_WARD 
actcond 

arrival:   ARRIVAL(identif ied) 
precondition 

already_assigned?:   not  ASSIGNED?  (identified) 
postcondition 

assignment_complete? :  ASSIGNED? ( identified) 
constraint 

si:   DFD.il  =  identified 

s2:   DFD.ol  =  assigned 

s3:   DFD.cl  =  ward 
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PERFORMJTESTS  part-of  ADMIT  with 
input 

assigned:   ASSIGNED_PATIENT 
output 

admitted:   ADMITTED_PATIENT 
control 

physician:   PHYSICIAN 

consulting_physician:   PHYSICIAN 
actcond 

arrival:   ARRIVAL(assigned) 
precondition 

already_pretested?:   not  PRETESTED? (assigned) 
postcondition 

pretest_complete? :  PRETESTED? (assigned ) 
component 

urinalysis:   URINALYSIS 

blood_count:   TAKE_BL00D_C0UNT 

blood_pressure :   TAKE_BL00D_PRESSURE 

temp:   TAKE_TEMP 
constraint 

si:   DFD.il  ■  assigned 

s2:   DFD.ol  =  admitted 

s3:   DFD.cl  =  physician 

s4:   DFD.c2  =  consulting_physician 

s5 :   DFD.boxl  =  urinalysis 

s6:   DFD.box2  =  blood_count 

s7:   DFD.box3  =  blood_pressure 

s8:   DFD.box4  =  temp 

dl:   DURING  (URINALYSIS,  PERF0RM_TESTS) 

d2:   DURING  (TAKE_BL00D_C0UNT,  PERF0RM_TESTS) 

d3:   DURING  (TAKE_BL00D_PRESSURE ,  PERFORMJTESTS) 

d4:   DURING  (TAKE_TEMP,  PERF0RM_TESTS) 

URINALYSIS  part-of  PERF0RM_TESTS  with 
input 

assigned:   ASSIGNED_PATIENT 
output 

analyzed:   ANALYZED_PATIENT 
actcond 

arrival:   ARRIVAL(assigned) 
precondition 

already_analyzed? :   not  ANALYZED? (assigned) 
postcondition 

analysis_complete? :   ANALYZED? (assigned) 
constraint 

si:   DFD.il  =  assigned 

s2:   DFD.ol  =  analyzed 
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TAKE_BLOOD_COUNT  part-of  PERFORM_TESTS  with 
input 

analyzed:   ANALYZED_PATIENT 
output 

blood_counted :   BLOOD_COUNTED_PATIENT 
actcond 

arrival:   ARRIVAL(analyzed) 
precondition 

already_counted?:   not  COUNTED? (analyzed) 
postcondition 

count_complete? :  COUNTED? (analyzed) 
constraint 

si:   DFD.il  =  analyze 

s2:   DFD.ol  =  blood_counted 

TAKE_BLOOD_PRESSURE  part-of  PERFORM_TESTS  with 
input 

blood_counted :   BLOOD_COUNTED_PATIENT 
output 

blood_pressured :   BLOOD_PRESSURED_PATIENT 
actcond 

arrival:   ARRIVAL(blood_counted ) 
precondition 

already_pressured? :    not  PRESSURED?  (blood_ 

counted) 
postcondition 

pressured?:  PRESSURED? (blood_counted) 
constraint 

si:   DFD.il  =  blood_counted 

s2:   DFD.ol  =  blood_pressured 

TAKEJTEMP  part-of  PERFORM_TESTS  with 
input 

blood_pressured :   BLOOD_PRESSURED_PATIENT 
output 

pretested:   PRETESTED_PATIENT 
actcond 

arrival :   ARRIVAL(blood_pressured) 
precondition 

already_temped? :   not  TEMPED? ( blood_pressured) 
postcondition 

temp_complete? :  TEMPED? (blood_pressured) 
constraint 

si:   DFD.il  =  blood_pressured 

s2:   DFD.ol  =  pretested 
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Constraints : 

A_PATIENT?  in  CONSTRAINT_CLASS  with 
argument 

person:   PERSON 
part 

patient?:   IN  (person,  PATIENT) 

R00M_LEFT  in  CONSTRAINT_CLASS  with 
constraint 

room?:   PATIENT. cardinality  <  PATIENT_MAX 

IN_HOSPITAL  in  CONSTRAINT_CLASS  with 

argument 

person:   PERSON 

part 

patient?:   A_PATIENT? ( person) 
present? :   PHYSICALLY_PRESENT( person) 

EVALUATED?  in  CONSTRAINT_CLASS  with 
argument 

patient:   PATIENT 
part 

evaluated?:   IN  (patient,  EVALUATED_PATIENT) 

TREATED?  in  CONSTRAINT_CLASS  with 
argument 

evaluated:   EVALUATED_PATIENT 
part 

treated?:   IN  (evaluated,  TREATED_PATIENT) 

EXAMINED?  in  CONSTRAINT_CLASS  with 
argument 

patient:   PATIENT 
part 

examined?:   IN  (patient,  EXAMINED_PATIENT) 


TESTED?  in  CONSTRAINT_CLASS  with 
argu 

part 


argument 

examined:   EXAMINED  PATIENT 


"tested?:   IN  (examined,  TESTED_PATIENT) 

ASSESSED?  in  CONSTRAINT_CLASS  with 
argument 

tested:   TESTED_PATIENT 
part 

assessed?:   IN  (tested,  EVALUATED_PATIENT) 
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IDED?  in  CONSTRAINT_CLASS  with 
argument 

patient:   PATIENT 
part 

examined?:   IN  (patient,  EXAMINED_PATIENT) 


ASSIGNED?  in  CONSTRAINT_CLASS  with 
argu 

part 


argument 

identified:   IDENTIFIED  PATIENT 


"assigned?:   IN  (identified,  ASSIGNED_PATIENT) 

PRETESTED?  in  CONSTRAINT_CLASS  with 
argument 

assigned:   ASSIGNED_PATIENT 
part 

pretested?:   IN  (assigned,  ADMITTED_PATIENT) 


COUNTED?  in  CONSTRAINT_CLASS  with 
argu 

part 


argument 

analyzed:   ANALYZED  PATIENT 


counted?:   IN  (analyzed,  BLOOD_COUNTED_PATIENT) 


ANALYZED?  in  CONSTRAINT_CLASS  with 
argu 

part 

PRESSURED?  in  CONSTRAINT_CLASS  with 
argu 

part 


argument 

assigned:   ASSIGNED_PATIENT 

"analyzed?:   IN  (assigned,  ANALYZED_PATIENT) 


argument 

blood  counted:   BLOOD  COUNTED  PATIENT 


pressured?:   IN  ( blood_counted ,  BLOOD_PRESSURED 

PATIENT) 

TEMPED?  in  CONSTRAINT_CLASS  with 
argument 

blood_pressured :   BLOOD_PRESSURED_PATIENT 
part 

temped?:   IN  ( blood_pressured ,  PRETESTED_PATIENT) 
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